Re: [mh] Alexa bridge suddenly stopped working

That was going to be the next thing I tried to do. I had originally removed
as much as it would let me to allow for discovering more devices but now
that it supports gzip compression, it doesn't matter as much. I think the
best way to handle this in the AlexaBridge code is to return the longer
discovery response when the Accept-Encoding: gzip header is set (because
that's an easy identifier that this is the new Echo code version) and the
old short one when its not set because for whatever reason my Echos are
still using the old method.

BTW you don't need "alexaHttpPortCount = 0", that was for if you wanted to
set the port for the alexa bridge different from the MH web server (so if
you used iptables or a reverse proxy to forward the Echo traffic to the MH
web server) and didn't want the alexa bridge code to spawn a proxy port.

alexaEnableChunked = 1 << FYI this was another method of increasing the
amount of devices that the Echo can discover from MH, the Echo makes
multiple gets during discovery and we return a different group of X amount
of devices for every get that it makes because each get has a size
limitation. This size limitation should be increased by using gzip
compression. This behaviour may have changed with the new Echo version, you
can test by decreasing  alexaObjectsPerGet to 10 and see if it can discover
more than 10 devices.

alexaObjectsPerGet = 300 << This is the amount of devices described in the
statement above, be aware that with the increased size of each device that
this number might need to be decreased. I don't know what it will be with
gzip compression, possibly no change at all. Also, if you have less that
300 devices then alexaEnableChunked = 1 has no effect because they will all
be in the first response to the Echo.


While on this subject, if you want to run MH on the old port 8080 so MH
does not have to run as root, you can use this mh.priviate.ini config:
alexaHttpPort=80
alexaHttpPortCount = 0

Then use iptables to pat port 80 to port 8080 (or whatever the MH web
server is listening on)
sudo iptables -t nat -A PREROUTING -p tcp -m tcp --dport 80 -j REDIRECT
--to-ports 8080

You could also use apache reverse proxy (instead of iptables) and allow the
echo traffic through unauthenticated.


_Wayne


On Thu, Sep 26, 2019 at 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]> <[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