Re: [mh] Alexa bridge suddenly stopped working
Giles Godart-Brown <[email protected]>
| Newsgroups | gmane.comp.misc.misterhouse.user |
|---|---|
| Message-ID | <[email protected]> |
All I’d like to re enable the Alexa bridge; was there a conclusion to this? If so could someone please let me know how to fix it, or better still update the docs if necessary? Thanks Giles > On 10 Oct 2019, at 04:43, Wayne Gatlin <[email protected]> wrote: > > > I looked over the code today, can you try adding these options? > > alexaEnableChunked = 1 > alexaObjectsPerGet = 300 > > Print.log is the only one I remember, but debug:9 might be too much. Try a lower level to get rid of the ssdp messages but still shows the http responses. Comment out all but 1 device in MH, restart MH and forget all devices in Alexa, then do a discover from Alexa. I want to see the MH responses for the discovery request. > > Make sure you do a full mh restart, not a reload after commenting the devices out. > > I really don't know how it could respond for a device in the discovery that is not configured in MH any where. I am going to do some tests with your config in my dev box tomorrow. > > > _Wayne > > >> On Wed, Oct 9, 2019, 10:03 AM Paul Onley <[email protected]> wrote: >> my mh.private.ini file currently has the following pertaining to alexa. >> >> password_allow_clients = 127\.0\.0\.1,192\.168\.2\..+,239.255.255.250 >> alexa_enable = 1 >> alexaHttpIp = 192.168.2.96 >> debug=alexa:9 >> >> This has not changed since I made the code changes suggested by Dan that got discovery working again. >> >> After deleting alexa_temp.saved_id alexa still discovers devices that are remarked with a "#" in the mht file and many items are not working, alexa responds "<item name> is not responding please check it's network connection and power supply" >> >> Which log file do you want to see? the only one I see alexa information in is the print.log file and there is a whole lot of alexa discovery traffic non stop. >> >> Thanks >> Paul >> >>> On 10/9/19 8:58 AM, Wayne Gatlin wrote: >>> Sorry for the late response. MH stores the UUID's in $::config_parms{'data_dir'}/alexa_temp.saved_id, which is the data_dir configured in your mh.private.ini. You should be able to delete the file and restart MH to regenerate the device to ID mappings. If you delete the file, you have to forget all the discovered devices in Alexa because Alexa calls them by the ID which is mapped to a name in that file. >>> >>> What mh.priviate.ini options do you have configured? MH should only advertise what is configured in the .mht file, not everything in the ID map file. >>> >>> _Wayne >>> >>> On Fri, Oct 4, 2019 at 12:12 PM Paul Onley <[email protected]> wrote: >>>> 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]> 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> 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]> 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] 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]> 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]> 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 check its 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]> 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]> 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]> 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]> >>>>>>>>> Sent: Friday, September 20, 2019 11:44 AM >>>>>>>>> To: [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] <[email protected]> >>>>>>>>> Sent: Monday, September 16, 2019 7:58 AM >>>>>>>>> To: [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 >>>> >> >> ________________________________________________________ >> 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