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/ 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 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/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 OKrn";
871 $output .= "Server: MisterHousern";
872 $output .= 'Access-Control-Allow-Origin: *' . "rn";
873 $output .= 'Access-Control-Allow-Methods: POST, GET, OPTIONS, DELETE, PUT' . "rn";
874 $output .= 'Access-Control-Max-Age: 3600' . "rn";
875 $output .= 'Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept' . "rn";
876 $output .= 'X-Application-Context: application' . "rn";
877 $output .= 'Content-Type: application/json;charset=UTF-8' . "rn";
878 #$output .= "Content-Encoding: gziprn" if ( $Http{'Accept-Encoding'} =~ m/gzip/ );
879 $output .= "Content-Length: " . ( length $content ) . "rn";
880 $output .= "Date: " . time2str(time) . "rn";
881 $output .= "rn";
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 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 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 (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 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 (http://HM-IP:port/docs/lib/AlexaBridge.html#AlexaBridge)
_Wayne
On Fri, Sep 20, 2019 at 1:39 PM Ron Fleming 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 (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
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]) (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 (https://lists.sourceforge.net/lists/listinfo/misterhouse-users)
________________________________________________________
To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users (https://lists.sourceforge.net/lists/listinfo/misterhouse-users)
________________________________________________________
To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users (https://lists.sourceforge.net/lists/listinfo/misterhouse-users)
________________________________________________________
To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.