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