Re: [mh] Alexa bridge suddenly stopped working
Paul Onley <[email protected]>
| Newsgroups | gmane.comp.misc.misterhouse.user |
|---|---|
| Message-ID | <[email protected]> |
I think the problem has to do with discovery. I removed all my alexa devices from my mht file and forgot all in the alexa web app. I then started adding them back one by one but on discovery with dan's new code alexa finds all the old devices. something somewhere is remembering them even though they are commented out in the mht file. I suspect it is as you suggested a sync problem with bad devices that are some how remembered. Is there somewhere I should look for a copy of the old devices in mh. Some kind of state log that it uses on restart that might be remembering the old devices? I will put together some logs tonight. Paul 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