Pi-Somfy
Pi-Somfy copied to clipboard
Nickduino
Alexa can't find my blinds
Hi,
I have the same (or very similar) problem as reported in issue 46. That bug seems to have been closed without resolution but the instructions in this comment indicated that it would be helpful to attempt to replicate the issue with the same hardware using the dev mode of fauxmo.
I installed the stand alone package of fauxmo on the same Pi and stopped the Pi-Somfy, then I copied the example config.json and ran fauxmo. Using this setup I was able to have my Echo discover all the fake devices in the example config.json. It worked first time but it also dumped a trace.
That seems to have been benign tho because I am able to tell Alexa to turn on/off the discovered devices (which results in more spew as it tries to hit the fake URLs in the config.json).
I'm hoping that this will be useful in pinning the issue down?
For context here's some more info:
HARDWARE Raspberry Pi 3A <--- Fresh install with just Pi-Somfy (and now fauxmo as well) Echo Dot 3rd Gen These devices are both on the same SSID/VLAN
I've also included a section of my operateshutters.log which I think illustrates the same problem as the original bug (I have not gone through the steps to add additional logging, but happy to do so if needed).
Other Observations
- Initially I was stupid and had the Dot and RPI on different VLANs - in this config I unsurprisingly had nothing in the log at all
- At this point I tried the Wemo app and there was also nothing
- Then I realised the RPI was on the wrong VLAN and moved it over
- Alexa didn't change behaviour in any way, but the Wemo app did (it now sticks on searching forever, whereas before it just said 'no devices' right away)
LMK if I can fiddle around with anything else? I have cloned master of fauxmo, but 2 seconds of diffing between that and the fauxmo.py code in Pi-somfy made it clear that I can't just drop in the new one and expect it to work :)
That bug seems to have been closed without resolution
Well, with no answer in three months, it seemed ok to close it at the time. It was solved for nstone33 by using Python 3 instead of 2.7, though.
LMK if I can fiddle around with anything else?
If I were you, I'd try sniffing the traffic, it did help me in the past: https://github.com/n8henrie/fauxmo/issues/72 I can't assist you, though, as I suck at everything networking.
Well, with no answer in three months, it seemed ok to close it at the time. It was solved for nstone33 by using Python 3 instead of 2.7, though.
I wasn't suggesting that it shouldn't have been closed, just that because there was no resolution I thought it would be ok to report essentially the same problem.
If I were you, I'd try sniffing the traffic, it did help me in the past: n8henrie/fauxmo#72
I gave this a go, but it doesn't seem that I'm having the same problem.
(RPI is 192.168.2.11 and Echo Dot is 192.168.2.12)
pi@somfy-pi:~/Pi-Somfy $ sudo tshark -f "host 192.168.2.12" -Y "udp"
Running as user "root" and group "root". This could be dangerous.
Capturing on 'wlan0'
1 0.000000000 192.168.2.12 → 239.255.255.250 SSDP 1066 M-SEARCH * HTTP/1.1
2 0.001647857 192.168.2.12 → 239.255.255.250 SSDP 1066 M-SEARCH * HTTP/1.1
3 0.003324152 192.168.2.12 → 239.255.255.250 SSDP 1066 M-SEARCH * HTTP/1.1
4 0.005038363 192.168.2.12 → 239.255.255.250 SSDP 1066 M-SEARCH * HTTP/1.1
5 0.006894292 192.168.2.12 → 239.255.255.250 SSDP 1066 M-SEARCH * HTTP/1.1
6 0.008810326 192.168.2.12 → 239.255.255.250 SSDP 1066 M-SEARCH * HTTP/1.1
7 0.512328675 192.168.2.11 → 192.168.2.12 UDP 429 43986 → 50000 Len=387
13 1.034742410 192.168.2.11 → 192.168.2.12 UDP 429 38831 → 50000 Len=387
14 1.119557608 192.168.2.12 → 224.0.0.251 MDNS 75 Standard query 0x0000 PTR _ipp._tcp.local, "QM" question
15 1.557169166 192.168.2.11 → 192.168.2.12 UDP 429 56219 → 50000 Len=387
21 3.068940149 192.168.2.12 → 224.0.0.251 MDNS 75 Standard query 0x0000 PTR _ipp._tcp.local, "QM" question
22 7.054201628 192.168.2.12 → 224.0.0.251 MDNS 75 Standard query 0x0000 PTR _ipp._tcp.local, "QM" question
23 15.041038716 192.168.2.12 → 224.0.0.251 MDNS 75 Standard query 0x0000 PTR _ipp._tcp.local, "QM" question
24 31.102573118 192.168.2.12 → 224.0.0.251 MDNS 75 Standard query 0x0000 PTR _ipp._tcp.local, "QM" question
14 packets captured
... and then:
pi@somfy-pi:~/Pi-Somfy $ sudo tshark -f "host 192.168.2.12 && host 192.168.2.11"
Running as user "root" and group "root". This could be dangerous.
Capturing on 'wlan0'
1 0.000000000 192.168.2.11 → 192.168.2.12 UDP 429 41144 → 50000 Len=387
2 0.008473245 192.168.2.12 → 192.168.2.11 TCP 74 57042 → 54337 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=10395591 TSecr=0 WS=32
3 0.008582047 192.168.2.11 → 192.168.2.12 TCP 74 54337 → 57042 [SYN, ACK] Seq=0 Ack=1 Win=65160 Len=0 MSS=1460 SACK_PERM=1 TSval=2980231796 TSecr=10395591 WS=64
4 0.014067909 192.168.2.12 → 192.168.2.11 TCP 66 57042 → 54337 [ACK] Seq=1 Ack=1 Win=29216 Len=0 TSval=10395592 TSecr=2980231796
5 0.014261710 192.168.2.12 → 192.168.2.11 TCP 164 GET /setup.xml HTTP/1.1 [TCP segment of a reassembled PDU]
6 0.014309783 192.168.2.11 → 192.168.2.12 TCP 66 54337 → 57042 [ACK] Seq=1 Ack=99 Win=65088 Len=0 TSval=2980231802 TSecr=10395592
7 0.522011777 192.168.2.11 → 192.168.2.12 UDP 429 60548 → 50000 Len=387
8 0.534660317 192.168.2.11 → 192.168.2.12 HTTP/XML 1426 HTTP/1.1 200 OK
9 0.552712479 192.168.2.12 → 192.168.2.11 TCP 66 57042 → 54337 [ACK] Seq=99 Ack=1361 Win=31936 Len=0 TSval=10395725 TSecr=2980232322
10 0.552945186 192.168.2.12 → 192.168.2.11 HTTP 66 GET /setup.xml HTTP/1.1
11 0.553473101 192.168.2.11 → 192.168.2.12 TCP 66 54337 → 57042 [FIN, ACK] Seq=1361 Ack=100 Win=65088 Len=0 TSval=2980232341 TSecr=10395726
12 0.577886694 192.168.2.12 → 192.168.2.11 TCP 66 57042 → 54337 [ACK] Seq=100 Ack=1362 Win=31936 Len=0 TSval=10395730 TSecr=2980232341
12 packets captured
Digging in a little further it looks from the operateshutters.log that the Echo is in fact reaching the RPI:
pi@somfy-pi:~/Pi-Somfy $ tail -f /var/log/operateShutters.log
2020-06-17 23:21:45,443 : [DEBUG] (MainThread) Loading Schedule from Config File
2020-06-17 23:21:45,455 : [INFO] (Scheduler ) Today is 2020/06/17, a Wed, Sunrise is at 04:45:06.389995 and Sunset is at 21:21:34.656400
2020-06-17 23:21:45,455 : [INFO] (Alexa ) Entering fauxmo polling loop
2020-06-17 23:21:45,456 : [INFO] (MQTT ) Entering MQTT polling loop
2020-06-17 23:21:45,456 : [DEBUG] (Scheduler ) {}
2020-06-17 23:21:45,463 : [INFO] (MainThread) Starting WebServer on Port 80
2020-06-17 23:22:12,248 : [DEBUG] (Alexa ) HANDLE REQUEST: b'GET /setup.xml HTTP/1.1\r\nHost: 192.168.2.11:54337\r\nAccept: */*\r\nContent-Type: application/json\r\n\r\n'
2020-06-17 23:22:12,249 : [INFO] (Alexa ) Responding to setup.xml for Somfy Blinds
2020-06-17 23:22:13,304 : [DEBUG] (Alexa ) HANDLE REQUEST: b'GET /setup.xml HTTP/1.1\r\nHost: 192.168.2.11:54337\r\nAccept: */*\r\nContent-Type: application/json\r\n\r\n'
2020-06-17 23:22:13,305 : [INFO] (Alexa ) Responding to setup.xml for Somfy Blinds
I dug around in fauxmo.py and replaced the commented out print call on line 246 with a self.LogDebug so that the response to the setup.xml request would be dumped:
2020-06-17 23:25:49,439 : [DEBUG] (Alexa ) responsed to setup-->HTTP/1.1 200 OK
CONTENT-LENGTH: 1125
CONTENT-TYPE: text/xml
DATE: Wed, 17 Jun 2020 22:25:49 GMT
LAST-MODIFIED: Sat, 01 Jan 2000 00:01:15 GMT
SERVER: Unspecified, UPnP/1.0, Unspecified
X-User-Agent: redsonic
CONNECTION: close
<?xml version=1.0?>
<root>
<device>
<deviceType>urn:Belkin:device:controllee:1</deviceType>
<friendlyName>Somfy Blinds</friendlyName>
<manufacturer>Belkin International Inc.</manufacturer>
<modelName>Socket</modelName>
<modelNumber>3.1415</modelNumber>
<modelDescription>Belkin Plugin Socket 1.0</modelDescription>
<UDN>uuid:Socket-1_0-48a536f6d66792</UDN>
<serialNumber>221517K0101769</serialNumber>
<binaryState>0</binaryState>
<serviceList>
<service>
<serviceType>urn:Belkin:service:basicevent:1</serviceType>
<serviceId>urn:Belkin:serviceId:basicevent1</serviceId>
<controlURL>/upnp/control/basicevent1</controlURL>
<eventSubURL>/upnp/event/basicevent1</eventSubURL>
<SCPDURL>/eventservice.xml</SCPDURL>
</service>
</serviceList>
</device>
</root>
This response 'looks fine' to me, looking at the code it seems like we're expecting the echo to send a follow up request which contains "SOAPACTION: "urn:Belkin:service:basicevent:1#SetBinaryState"" or similar... but this never appears, which suggests that the echo doesn't like something from the setup.xml response.
Can someone dump this response from a successful discovery so I can compare?
Hi i have the same issue:
2020-07-03 13:29:11,909 : [DEBUG] (MainThread) addEvent: Lock aquired
2020-07-03 13:29:11,909 : [DEBUG] (MainThread) addEvent: Lock released
2020-07-03 13:29:11,910 : [DEBUG] (MainThread) Loading Scheudle 7
2020-07-03 13:29:11,910 : [DEBUG] (MainThread) addEvent: Waiting for Lock
2020-07-03 13:29:11,911 : [DEBUG] (MainThread) addEvent: Lock aquired
2020-07-03 13:29:11,911 : [DEBUG] (MainThread) addEvent: Lock released
2020-07-03 13:29:11,923 : [INFO] (Scheduler ) Today is 2020/07/03, a Fri, Sunrise is at 05:20:27.968930 and Sunset is at 21:36:43.630506
2020-07-03 13:29:11,923 : [INFO] (Alexa ) Entering fauxmo polling loop
2020-07-03 13:29:11,924 : [DEBUG] (Scheduler ) {}
2020-07-03 13:29:11,955 : [INFO] (MainThread) Starting WebServer on Port 80
2020-07-03 13:29:19,087 : [DEBUG] (Alexa ) HANDLE REQUEST: b'GET /setup.xml HTTP/1.1\r\nHost: 192.168.178.100:54337\r\nAccept: */*\r\nContent-Type: application/json\r\n\r\n'
2020-07-03 13:29:19,089 : [INFO] (Alexa ) Responding to setup.xml for Büro
2020-07-03 13:29:22,123 : [DEBUG] (Alexa ) HANDLE REQUEST: b'GET /setup.xml HTTP/1.1\r\nHost: 192.168.178.100:54338\r\nAccept: */*\r\nContent-Type: application/json\r\n\r\n'
2020-07-03 13:29:22,124 : [INFO] (Alexa ) Responding to setup.xml for Wohnzimmer
2020-07-03 13:29:22,178 : [DEBUG] (Alexa ) HANDLE REQUEST: b'GET /setup.xml HTTP/1.1\r\nHost: 192.168.178.100:54339\r\nAccept: */*\r\nContent-Type: application/json\r\n\r\n'
2020-07-03 13:29:22,180 : [INFO] (Alexa ) Responding to setup.xml for Balkon
2020-07-03 13:29:22,203 : [DEBUG] (Alexa ) HANDLE REQUEST: b'GET /setup.xml HTTP/1.1\r\nHost: 192.168.178.100:54340\r\nAccept: */*\r\nContent-Type: application/json\r\n\r\n'
2020-07-03 13:29:22,205 : [INFO] (Alexa ) Responding to setup.xml for Küche
2020-07-03 13:29:22,228 : [DEBUG] (Alexa ) HANDLE REQUEST: b'GET /setup.xml HTTP/1.1\r\nHost: 192.168.178.100:54341\r\nAccept: */*\r\nContent-Type: application/json\r\n\r\n'
2020-07-03 13:29:22,230 : [INFO] (Alexa ) Responding to setup.xml for Kinderzimmer
2020-07-03 13:29:22,253 : [DEBUG] (Alexa ) HANDLE REQUEST: b'GET /setup.xml HTTP/1.1\r\nHost: 192.168.178.100:54342\r\nAccept: */*\r\nContent-Type: application/json\r\n\r\n'
2020-07-03 13:29:22,255 : [INFO] (Alexa ) Responding to setup.xml for Schlafzimmer
But my Alexa tells me that there are no devices
Same issue, It was working until I had to do a fresh install on the raspberry. HASS works, MQTT works, Webinterface works but Alexa is not discovering the devices. Checking the log I can also see the service is responding the initial response, but there is no follow up.
Set up:
- RPI 4
- Router eero
- Have tried with an Echo Show, a Echo 2, and an Echo dot, no luck
Thanks Alvaro
I have the same issue everything works except for Alexa discovering the device. This is the only thing I get in the logs.
~ $ sudo tail shtail -f /var/log/operateShutters.log tail: cannot open 'shtail' for reading: No such file or directory ==> /var/log/operateShutters.log <== 2020-09-27 16:13:56,659 : [DEBUG] (Alexa ) HANDLE REQUEST: b'GET /setup.xml HTTP/1.1\r\nUser-A gent: UPnP/1.0 DLNADOC/1.50 Kodi\r\nHost: 192.168.0.125:54337\r\n\r\n' 2020-09-27 16:13:56,660 : [INFO] (Alexa ) Responding to setup.xml for projector 2020-09-27 16:14:50,129 : [DEBUG] (Alexa ) HANDLE REQUEST: b'GET /setup.xml HTTP/1.1\r\nUser-A gent: UPnP/1.0 DLNADOC/1.50 Kodi\r\nHost: 192.168.0.125:54337\r\n\r\n' 2020-09-27 16:14:50,131 : [INFO] (Alexa ) Responding to setup.xml for projector 2020-09-27 16:15:44,129 : [DEBUG] (Alexa ) HANDLE REQUEST: b'GET /setup.xml HTTP/1.1\r\nUser-A gent: UPnP/1.0 DLNADOC/1.50 Kodi\r\nHost: 192.168.0.125:54337\r\n\r\n' 2020-09-27 16:15:44,130 : [INFO] (Alexa ) Responding to setup.xml for projector 2020-09-27 16:16:38,629 : [DEBUG] (Alexa ) HANDLE REQUEST: b'GET /setup.xml HTTP/1.1\r\nUser-A gent: UPnP/1.0 DLNADOC/1.50 Kodi\r\nHost: 192.168.0.125:54337\r\n\r\n' 2020-09-27 16:16:38,630 : [INFO] (Alexa ) Responding to setup.xml for projector 2020-09-27 16:17:31,948 : [DEBUG] (Alexa ) HANDLE REQUEST: b'GET /setup.xml HTTP/1.1\r\nUser-A gent: UPnP/1.0 DLNADOC/1.50 Kodi\r\nHost: 192.168.0.125:54337\r\n\r\n' 2020-09-27 16:17:31,949 : [INFO] (Alexa ) Responding to setup.xml for projector
I had a couple of higher-priority problems to address but I'm intending to get back to this soon.
I was able to make a bit more progress than I made here. I downloaded the latest version of fauxmo and everything works fine for it. The code which manages this bit of the negotiation has diverged significantly from what Pi-Somfy is currently using. I think it's a reasonable hypothesis that:
- there's been some minor behaviour change between older and newer echos
- this has been addressed in later versions of fauxmo (unclear whether it's intentional or a side effect of what seems to have been a fairly large re-write
Next time I have cycles for this I'm going to bisect the entire negotiation process between my echo and the test harness for the latest version of fauxmo and do the same for pi-somfy. There were only small deltas when I did this before so I suspect/hope that the fix will be minor. Of course, if someone else got there first that would be awesome :)
A bit off topic but does someone know how I can prevent the web interface from starting up? In systemctl shutters.service is already disabled, also moved away the -a part from the shutters.service file..
hey toegether, I got the same issue, that Alexa can not find anything. I installed this on a zero w. I flashed a new card and only followed the description here. Is there a easy solution. Someone tried to install fauxmo extra with the new version and extra skript maybe?
