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