Re: [mh] Alexa bridge suddenly stopped working
Paul Onley <[email protected]>
| Newsgroups | gmane.comp.misc.misterhouse.user |
|---|---|
| Message-ID | <[email protected]> |
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] >> <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