Re: [mh] Alexa bridge suddenly stopped working

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>
>>> <http://mh_ip_address/api/lights/lights/> 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]>
>>> <[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
>>>
>>>
>>>
>>> ________________________________________________________
>>> 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