Re: [mh] Alexa bridge suddenly stopped working
Paul Onley <[email protected]>
| Newsgroups | gmane.comp.misc.misterhouse.user |
|---|---|
| Message-ID | <[email protected]> |
Looking at my logs the problem is related to my last post, Alexa is discovering devices that have been removed from my .mht file resulting in a number of these entries in the logs *10/03/19 08:09:24 PM [Alexa] Error: No Matching object for UUID ( 25 )** **10/03/19 08:09:24 PM [Alexa] Debug: MH Response HTTP/1.1 404 Not Found** **Server: MisterHouse** **Cache-Control: no-cache** **Content-Length: 2** **Date: Fri, 04 Oct 2019 01:09:24 GMT** ** **.. * As I said, I have pared down my devices in the .mht file and done "forget all" in the alexa web app numerous times but alexa still discovers every device I ever had in my .mht file. I do not know where alexa is discovering these old devices from. On 10/2/19 7:49 PM, Wayne Gatlin wrote: > Paul, > > Can you enable the debug and try to control a few devices, 1 that > works and 1 that doesn't and send the log out? > > They are all discovered as identical devices except for the name you > give them in MH, the device number which is generated by the > AlexaBridge code, and the state (on/off/brightness). > > _Wayne > > On Wed, Oct 2, 2019 at 7:42 AM <[email protected] > <mailto:[email protected]>> wrote: > > Interesting. All my devices work fine, in my case, all except my > thermostat are modified Neo wall switches running custom code or > DIY esp8266 devicesrunning a modified version of "sonoff tasmota" > code. Basically ON/OFF only. > > Which devices are not working correctly? > > The issue might be the mismatch between what we are sending when > we get a http://mh_ip_address/api/lights/lights (discovery), and > what MH returns when Alexa is requesting status > http://mh_ip_address/api/lights/<deviceNumber> > <http://mh_ip_address/api/lights/lights/> could be the issue. > > If that is the case, will need to modify the highlighted code to > match. > > if ( defined $uris[4] ) { > if ( ( $uris[3] eq 'lights' ) && ( > $AlexaObjects->{'uuid'}->{ $uris[4] } ) ) { > $uuid = $uris[4]; > $name = $AlexaObjects->{'uuid'}->{$uuid}->{'name'}; > my $state = &get_set_state( $self, $AlexaObjects, > $uuid, 'get' ); > * $statep1 = > qq[{"state":{$state,"hue":15823,"sat":88,"effect":"none","ct":313,"alert":"none","colormode":"ct","reachable":true,"xy":\[0.4255,0.3998\]},"type":"Extended > color light","name":"]; > $statep2 = > qq[","modelid":"LCT001","manufacturername":"Philips","uniqueid":"$uuid","swversion":"65003148","pointsymbol":{"1":"none","2":"none","3":"none","4":"none","5":"none","6":"none","7":"none","8":"none"}}]; > * $content = $statep1 . $name . $statep2; > $count = 1; > } > > > Below is a data capture from an official Hue returning the status > of bulb I used in patching the discovery: > > {"state":{"on":false,"bri":128,"alert":"select","mode":"homeautomation","reachable":true},"swupdate":{"state":"readytoinstall","lastinstall":null},"type":"Dimmable > light","name":"Lamp","modelid":"LWB014","manufacturername":"Philips","productname":"Hue > white > lamp","capabilities":{"certified":true,"control":{"mindimlevel":5000,"maxlumen":840},"streaming":{"renderer":false,"proxy":false}},"config":{"archetype":"classicbulb","function":"functional","direction":"omnidirectional"},"uniqueid":"00:17:88:01:04:00:3d:96-0b","swversion":"1.23.0_r20156","swconfigid":"321D79EA","productid":"Philips-LWB014-1-A19DLv4"} > > > > > > On Tue, Oct 1, 2019 at 16:35, Paul Onley <[email protected] > <mailto:[email protected]>> wrote: > > I spoke prematurely, Alexa can now discover my devices (Mostly > lights on x10 switches) but they are identified in the web app > as "Royal Philips Electronics smart device" and when I ask > alexa to turn one on she responds "_ device does not support > that" to some and others work. I can now discover my devices > but cannot reliably control them. > > > On 10/1/19 2:32 PM, Paul Onley wrote: >> Wayne, >> >> Sorry, I've been out of town for a few days. I had the same >> problem as Dan, I had deleted all my devices and was unable >> to discover them. >> >> Dan, I edited Alexabridge.pm with your code and am again able >> to discover devices. Thank You for your help. >> >> Paul >> >> On 9/26/19 1:16 PM, [email protected] >> <mailto:[email protected]> wrote: >>> Wayne, >>> >>> Didn't help removing the gzip... *but I have good news is I >>> have successfully discovered all my devices and are able to >>> control them. Including my HVAC controls :)* >>> >>> >>> However, after capturing packets during the discovery phase >>> from both MH and the Hue bridge I purchased, I noticed >>> considerable differences in the data packets during discovery. >>> >>> I made the following changes to Alexabridge.pm in at around >>> line #800 in the function that handles the http call: >>> http://mh_ip_address/api/lights/lights during discovery. >>> >>> elsif ( defined $uris[3] ) { >>> if ( $uris[3] eq 'lights' ) { >>> $AlexaObjChunk = $self->_GetChunk( $uris[3] >>> ) if ( $::config_parms{'alexaEnableChunked'} ); >>> foreach my $uuid ( keys %{ >>> $AlexaObjChunk->{'uuid'} } ) { >>> $name = >>> $AlexaObjChunk->{'uuid'}->{$uuid}->{'name'}; >>> next unless $name; >>> my $state = &get_set_state( $self, >>> $AlexaObjects, $uuid, 'get' ); >>> &main::print_log("[Alexa]: state=$state uuid=$uuid name=$name"); >>> * $statep1 = qq[{"]; >>> $statep2=qq[":{"state":{$state,"alert": "select","mode": >>> "homeautomation","reachable": true},"swupdate": {"state": >>> "readytoinstall","lastinstall": null},"type": "Dimmable >>> light","name": "]; >>> $statep3=qq[","modelid": >>> "LWB014","manufacturername": "Philips","productname": "Hue >>> white lamp","capabilities": {"certified": true,"control": >>> {"mindimlevel": 5000,"maxlumen": 840},"streaming": >>> {"renderer": false,"proxy": false}},"config": {"archetype": >>> "classicbulb","function": "functional","direction": >>> "omnidirectional"},"uniqueid": >>> "00:17:88:01:04:00:3d:96-0b","swversion": >>> "1.23.0_r20156","swconfigid": "321D79EA","productid": >>> "Philips-LWB014-1-A19DLv4"}];* >>> $end = qq[}]; >>> $delm = qq[,"]; >>> if ( $count >= 1 ) { $content = >>> $content . $delm . $uuid . $statep2 . $name . $statep3 } >>> else { $content = >>> $statep1 . $uuid . $statep2 . $name . $statep3 } >>> $count++; >>> } >>> } >>> >>> I may make changes to the code that handles >>> http://mh_ip_address/api/lights/lights/<deviceNumber> to >>> match what the Hue is sending. However, MH/Alexa is working >>> fine without those changes. >>> >>> >>> >>> I am now running MH on port 80 using these settings: >>> alexa_enable = 1 >>> alexaEnableChunked = 1 >>> alexaHttpPortCount = 0 >>> alexaObjectsPerGet = 300 >>> #debug=alexa:9 >>> >>> >>> Thanks to everyone that responded to my original query! >>> Dan >>> >>> >>> >>> >>> >>> On Thu, Sep 26, 2019 at 10:47, Wayne Gatlin >>> <[email protected]> <mailto:[email protected]> wrote: >>> >>> I see in your logs that the Echo is making the request >>> with the Accept-Encoding: gzip http header which >>> triggers MH to respond with a gzip compressed response, >>> this is new for the Echo and my Echos do not seem to be >>> doing that (yet). Maybe the echo still does not support >>> gzip compression and sending an improper request. It's >>> also possible that its looking for a specific case in >>> our Content-Encoding: gzip response header and we will >>> see that in the capture of the real Hue bridge. >>> >>> To make this faster, comment lines 869 and 878 in >>> <MH_ROOT>/mh/lib/AlexaBridge.pm, restart MH, and >>> rediscover. The line numbers could be a little different >>> in your file, so make sure its the 2 lines below: >>> >>> 867 $content = $content . $end; >>> 868 $debugcontent = $content if >>> $main::Debug{'alexa'} >= 2; >>> * 869 #$content = &_Gzip( $content, >>> $Http{'Accept-Encoding'} );* >>> 870 $output = "HTTP/1.1 200 OK\r\n"; >>> 871 $output .= "Server: MisterHouse\r\n"; >>> 872 $output .= >>> 'Access-Control-Allow-Origin: *' . "\r\n"; >>> 873 $output .= >>> 'Access-Control-Allow-Methods: POST, GET, OPTIONS, >>> DELETE, PUT' . "\r\n"; >>> 874 $output .= 'Access-Control-Max-Age: >>> 3600' . "\r\n"; >>> 875 $output .= >>> 'Access-Control-Allow-Headers: Origin, X-Requested-With, >>> Content-Type, Accept' . "\r\n"; >>> 876 $output .= 'X-Application-Context: >>> application' . "\r\n"; >>> 877 $output .= 'Content-Type: >>> application/json;charset=UTF-8' . "\r\n"; >>> * 878 #$output .= "Content-Encoding: >>> gzip\r\n" if ( $Http{'Accept-Encoding'} =~ m/gzip/ );* >>> 879 $output .= "Content-Length: " . ( >>> length $content ) . "\r\n"; >>> 880 $output .= "Date: " . time2str(time) . >>> "\r\n"; >>> 881 $output .= "\r\n"; >>> 882 $debugcontent = $output . $debugcontent >>> if $main::Debug{'alexa'} >= 2; >>> 883 $output .= $content; >>> >>> >>> If this does not resolve the issue, then we might need >>> to add some lines to our light discovery response. I >>> removed a good bit of the response because the echo >>> could discover more devices in 1 request with smaller >>> responses but it might be using/wanting some of those >>> parameters now with the new version. >>> >>> _Wayne >>> >>> On Thu, Sep 26, 2019 at 6:54 AM <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Wayne, >>> >>> It would seem the problem is not unique to the >>> AlexaBridge in Misterhouse. I found several other >>> Hue emulators reporting the same issue. >>> >>> Original issue was:"Devicename is not responding, >>> please checkits network connection..." >>> >>> Here's what I have done: >>> Moved MH to port 80 from 8080 >>> Disabled chunk mode >>> Removed all devices from Alexa app >>> Removed all devices from MH, except for 1 >>> >>> Discover devices returns "No devices found" in all >>> cases. >>> >>> I ordered a real hue and 1 bulb from Amazon, >>> received yesterday. Did not have time to wireshark >>> the packets between it and Alexa. Plan on doing the >>> same for MH and comparing. >>> Yes, I'm that desperate to get this working again. I >>> have many DIY devices that can only be controlled by >>> Alexa or via http. >>> >>> Looking at the debug, it seems like Alexa keeps >>> asking for the devices over and over. See attached >>> log. Only 1 device defined for testing. >>> >>> Thank you >>> Dan >>> >>> >>> >>> On Wed, Sep 25, 2019 at 23:39, Wayne Gatlin >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>> Do you have "alexaEnableChunked=1" ? If so try >>> disabling it. It was just a way to allow the >>> echo to support more "hue lights" presented from >>> MH but it's possible the new echo code doesn't >>> like it. >>> >>> Do you still have the MH smart home devices >>> listed in the echo app? Or did you delete them? >>> If they aren't working anyway, you can try >>> deleting them from the app and see if it will >>> rediscover after that. The device IDs may be out >>> of sync between MH and the echo. >>> >>> To Delete from the app: >>> settings>device settings / click on each device >>> and click the trash at the top >>> >>> It's much easier to delete them from the web app: >>> https://alexa.amazon.com/spa/index.html#appliances >>> >>> If you want to send me some debugs I can take a >>> look at them when I get a chance. May need to >>> increase the debug level to see what it's doing. >>> >>> Just to be clear when you try to control a >>> device through the echo it says it's not >>> responding correct? >>> >>> _Wayne >>> >>> On Sun, Sep 22, 2019, 12:30 PM Paul Onley >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>> Thank you Wayne, >>> This gets me closer to fixing the problem. >>> When I switched to port 80 I now get all of >>> my devices listed in the debug log but alexa >>> still does not discover them. >>> >>> 09/22/19 12:27:05 PM [Alexa] Debug: >>> get_set_state (1 get ) : name: Livingroom >>> Light realname: $Livingroom_Light sub: set >>> state: >>> >>> I think there was an update to alexa but >>> that it changed more than just the port >>> requirements. >>> >>> Paul >>> >>> On 9/20/19 6:27 PM, Wayne Gatlin wrote: >>>> I have not run into the issue your guys are >>>> experiencing, maybe my echos have not been >>>> updated to that version yet. But if the >>>> port is the issue (Google Home has always >>>> been limited to port 80) then all you have >>>> to do it change the port that the MH web >>>> server is running on because the Alexa >>>> Bridge module advertises/uses the MH built >>>> in web server. >>>> >>>> Once you change the MisterHouse web server >>>> port to 80, all you should need in your >>>> mh.private.ini is: >>>> alexa_enable=1 >>>> alexaEnableChunked=1 >>>> >>>> To change the MH web server port use (the >>>> Alexa Bridge code uses this config for the >>>> SSDP messages) : >>>> http_port=80 >>>> >>>> >>>> Ron, >>>> >>>> I wrote a Misterhouse module that emulates >>>> a Hue bridge like the external java app you >>>> are running but its integrated into MH. You >>>> can see the documentation in the local MH >>>> docs @ >>>> http://HM-IP:port/docs/lib/AlexaBridge.html#AlexaBridge >>>> >>>> >>>> _Wayne >>>> >>>> >>>> On Fri, Sep 20, 2019 at 1:39 PM Ron Fleming >>>> <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> Paul, >>>> >>>> Perhaps my setup is a bit different. >>>> I am using bwssystem’s ha-bridge Java >>>> program to provide the bridge emulation : >>>> >>>> https://github.com/armzilla/amazon-echo-ha-bridge >>>> >>>> It has an habridge.config file that >>>> stores the bridge configuration >>>> including the Port. It can also be >>>> changed from the habridge web interface. >>>> >>>> You may be using a different bridge >>>> emulator, but I’ll bet the issue is the >>>> same. I am running an old version of >>>> mh and have my echo integration running >>>> outside of misterhouse. >>>> >>>> I hope that helps! >>>> >>>> Ron >>>> >>>> *From:*Paul Onley <[email protected] >>>> <mailto:[email protected]>> >>>> *Sent:* Friday, September 20, 2019 11:44 AM >>>> *To:* >>>> [email protected] >>>> <mailto:[email protected]> >>>> *Subject:* Re: [mh] Alexa bridge >>>> suddenly stopped working >>>> >>>> Ron, >>>> What did you have to do to configure >>>> for port 80? I have included >>>> >>>> mh.private.ini:alexaHttpPort = 80 >>>> >>>> in my mh.private.ini but still see >>>> >>>> 09/20/19 10:42:34 AM [Alexa] Debug: >>>> Configured for port 8080 >>>> >>>> during startup and am still unable to >>>> discover any devices. >>>> >>>> Thanks >>>> Paul >>>> >>>> >>>> On 9/20/19 8:35 AM, Ron Fleming wrote: >>>> >>>> Dan, I had the same issue. I >>>> think Amazon may have pushed >>>> changed out to the Echo devices. >>>> It would appear that they require >>>> the bridge to be on port 80. I >>>> had mh on 80 and the bridge on >>>> 8080. I started seeing unusually >>>> request in the mh http server log >>>> that I think were meant for the >>>> bridge. The quick fix for me was >>>> to put mh on 8080 and the bridge on >>>> 80. Hopefully Amazon will correct >>>> this and I can go back to my >>>> default configuration. >>>> >>>> Hope this helps. >>>> >>>> Ron >>>> >>>> *From:* [email protected] >>>> <mailto:[email protected]> >>>> <[email protected]> >>>> <mailto:[email protected]> >>>> *Sent:* Monday, September 16, 2019 >>>> 7:58 AM >>>> *To:* >>>> [email protected] >>>> <mailto:[email protected]> >>>> *Subject:* [mh] Alexa bridge >>>> suddenly stopped working >>>> >>>> Been using the Alexa bridge to MH >>>> for well over a year without >>>> issues. It was the last piece I >>>> needed to complete >>>> my HA integration. >>>> >>>> Tuesday of last week, 9/10, it >>>> suddenly stopped working. A >>>> request is answered with >>>> "Devicename is not responding, >>>> please check >>>> its network connection..." I tried >>>> debugging, but so far have not >>>> found a reason. >>>> It seems like Echo/Alexa does not >>>> even attempt to connect the the >>>> bridge. I did add a bogus device >>>> and asked >>>> Echo to discover devices, I do see >>>> traffic to MH at that point, but >>>> Echo comes back with"No new devices". >>>> >>>> Alexa app on my Android phone shows >>>> "Server is unresponsive". >>>> >>>> Has anyone else experienced this? >>>> >>>> Thanks >>>> Dan >>>> >>>> >>>> >>>> >>>> >>>> ________________________________________________________ >>>> >>>> To unsubscribe from this list, go to:https://lists.sourceforge.net/lists/listinfo/misterhouse-users >>>> >>>> >>>> >>>> >>>> ________________________________________________________ >>>> To unsubscribe from this list, go to: >>>> https://lists.sourceforge.net/lists/listinfo/misterhouse-users >>>> >>> >>> >>> ________________________________________________________ >>> To unsubscribe from this list, go to: >>> https://lists.sourceforge.net/lists/listinfo/misterhouse-users >>> >> >> >> >> >> ________________________________________________________ >> To unsubscribe from this list, go to:https://lists.sourceforge.net/lists/listinfo/misterhouse-users >> > > > ________________________________________________________ > To unsubscribe from this list, go to: > https://lists.sourceforge.net/lists/listinfo/misterhouse-users > ________________________________________________________ To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users