SOMFY: "Geistergeräte"

[mahura]

Hallo,

ich bin neu hier im Forum und sammle auch erst Erfahrungen auf dem Gebiet FHEM. Mithilfe diverser Beiträge habe ich schon mal FHEM auf einem RaspberryPI mit dem CUL 433MHz zum Laufen bekommen und meine ELRO 440 Funksteckdosen und SOMFY RTS Rollladen funktionieren soweit ganz gut. Nun habe ich jedoch noch das Problem dass in FHEM nach Betätigen der Rollläden über FHEM irgendwelche "Geistergeräte" von SOMFY auftauchen, das sieht dann so aus:

define SOMFY_222222 SOMFY 222222
attr SOMFY_222222 IODev CUL_0
attr SOMFY_222222 room SOMFY
define FileLog_SOMFY_222222 FileLog ./log/SOMFY_222222-%Y.log SOMFY_222222
attr FileLog_SOMFY_222222 logtype text
attr FileLog_SOMFY_222222 room SOMFY
define SOMFY_EEEEEE SOMFY EEEEEE
attr SOMFY_EEEEEE IODev CUL_0
attr SOMFY_EEEEEE room SOMFY
define FileLog_SOMFY_EEEEEE FileLog ./log/SOMFY_EEEEEE-%Y.log SOMFY_EEEEEE
attr FileLog_SOMFY_EEEEEE logtype text
attr FileLog_SOMFY_EEEEEE room SOMFY
define SOMFY_888888 SOMFY 888888
attr SOMFY_888888 IODev CUL_0
attr SOMFY_888888 room SOMFY
define FileLog_SOMFY_888888 FileLog ./log/SOMFY_888888-%Y.log SOMFY_888888
attr FileLog_SOMFY_888888 logtype text
attr FileLog_SOMFY_888888 room SOMFY
define SOMFY_BBBBBB SOMFY BBBBBB
attr SOMFY_BBBBBB IODev CUL_0
attr SOMFY_BBBBBB room SOMFY
define FileLog_SOMFY_BBBBBB FileLog ./log/SOMFY_BBBBBB-%Y.log SOMFY_BBBBBB
attr FileLog_SOMFY_BBBBBB logtype text
attr FileLog_SOMFY_BBBBBB room SOMFY
define SOMFY_AAAAAA SOMFY AAAAAA
attr SOMFY_AAAAAA IODev CUL_0
attr SOMFY_AAAAAA room SOMFY
define FileLog_SOMFY_AAAAAA FileLog ./log/SOMFY_AAAAAA-%Y.log SOMFY_AAAAAA
attr FileLog_SOMFY_AAAAAA logtype text
attr FileLog_SOMFY_AAAAAA room SOMFY

Und jemehr ich die Rollläden steuere umso mehr Geräte tauchen auf - was ist da los? Wie kann ich das verhindern?

Danke,

Viele Grüße
Lars

[viegener]

Ich kann erstmal noch keine Begründung geben, wie es zu diesen Geräten kommt. Es wäre vermutlich gut, ein Teil des Logfiles zu sehen (fhem log files, möglicherweise auch mit höherem log level -> verbose 5?).

Generell wird Somfy durch einen CUL ja nicht empfangen, so dass eigentlich auch kein autocreate die devices anlegen sollte.
Gibt es andere "Dinge", die automatisch bei Dir Geräte anlegen?

Ich kenne mich auch nicht wirklich mit autocreate aus, deshalb ist mir nicht klar, wie es zu diesen Devices kommen könnte.

[mahura]

Hallo,

ich habe nun verbose auf 5 gesetzt und mal das alte Logfile und die Zombies aus den Configs gelöscht. Danach FHEM sauber hochgefahren, einen Rollladen herunterfahren lassen und FHEM beendet.

Interessant ist der Auszug:

...
2016.03.22 21:03:51 5: Cmd: >set Rollladen_Wohnen2 My<
2016.03.22 21:03:51 4: SOMFY_set: Rollladen_Wohnen2 -> entering with mode :send: cmd :go-my:  arg1 ::  pos :open:
2016.03.22 21:03:51 1: PERL WARNING: Argument "open" isn't numeric in addition (+) at ./FHEM/10_SOMFY.pm line 956.
2016.03.22 21:03:51 3: SOMFY_set: handled command go-my --> move :stop:  newState :open:
2016.03.22 21:03:51 5: SOMFY_set: handled for drive/udpate:  updateState ::  drivet :0: updatet :0:
2016.03.22 21:03:51 4: SOMFY_sendCommand: Rollladen_Wohnen2 -> cmd :stop:
2016.03.22 21:03:51 4: SOMFY set Rollladen_Wohnen2 stop: sA5110005000002
2016.03.22 21:03:51 5: SOMFY_sendCommand: Rollladen_Wohnen2 -> message :sA5110005000002:
2016.03.22 21:03:51 5: CUL_0 sending YsA5110005000002
2016.03.22 21:03:51 5: SW: YsA5110005000002
2016.03.22 21:03:51 4: name: /fhem?cmd.Rollladen_Wohnen2=set%20Rollladen_Wohnen2%20My&room=Wohnen&XHR=1 / RL:20 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2016.03.22 21:03:52 5: CUL/RAW: /YsA5BCBCB9BBBBBB

2016.03.22 21:03:52 4: CUL_Parse: CUL_0 YsA5BCBCB9BBBBBB
2016.03.22 21:03:52 5: CUL_0 dispatch YsA5BCBCB9BBBBBB
2016.03.22 21:03:53 3: SOMFY Unknown device BBBBBB, please define it
2016.03.22 21:03:53 5: Triggering global (1 changes)
2016.03.22 21:03:53 5: Notify loop for global UNDEFINED SOMFY_BBBBBB SOMFY BBBBBB
2016.03.22 21:03:53 2: autocreate: define SOMFY_BBBBBB SOMFY BBBBBB
2016.03.22 21:03:53 5: Triggering global (2 changes)
2016.03.22 21:03:53 2: autocreate: define FileLog_SOMFY_BBBBBB FileLog ./log/SOMFY_BBBBBB-%Y.log SOMFY_BBBBBB
2016.03.22 21:03:53 5: Triggering global (3 changes)
2016.03.22 21:03:53 5: Triggering global (4 changes)
...

Mein CUL erkennt (empfängt) also ein SOMFY Signal !?!

Das gesamte Logfile kann ich gern per Mail/PN bereitstellen.

Btw. es werden keine weiteren Geräte mittels "autoload_undefined_devices" erkannt, nur die SOMFY Zombies.

Viele Grüße
Lars

[viegener]

Mein CUL erkennt (empfängt) also ein SOMFY Signal !?!

Nein, der CUL sendet das Kommando nochmals zurück, bei Dir scheint das kommando aber verstümmelt zurückzukommen.
Also erste Vermutung, Dein CUL verhält sich nicht korrekt.

Bei mir sieht so etwas im Log so aus:

Code Auswählen Erweitern


2016.03.22 22:39:55 4: SOMFY_set: roll_st -> entering with mode :send: cmd :on:  arg1 ::  pos :200:
2016.03.22 22:39:55 4: SOMFY_set: handled command on --> move :on:  newState :200:
2016.03.22 22:39:55 5: SOMFY_set: handled for drive/udpate:  updateState ::  drivet :0: updatet :0:
2016.03.22 22:39:55 4: SOMFY_sendCommand: roll_st -> cmd :on:
2016.03.22 22:39:55 5: SOMFY_sendCommand: roll_st -> message :sA84002F5DD0301:
2016.03.22 22:39:56 4: CUL_Parse: SCC2 YsA84C02F50103DD
2016.03.22 22:39:56 5: SCC2 dispatch YsA84C02F50103DD
2016.03.22 22:39:56 4: SOMFY roll_st on


Kann es sein, dass etwas mit der Firmware auf Deinem CUL nicht stimmt?

[mahura]

wie kann ich denn Prüfen ob die Firmware passt? Ich hatte mich beim Flashen an die Anleitung gehalten:

# sudo apt-get install dfu-programmer
# sudo apt-get install build-essential

Danach laden und entpacken wir die entsprechende Firmware (bitte auf neuere Version auf der Website prüfen).
# wget http://culfw.de/culfw-1.55.tar.gz
# gunzip culfw-1.55.tar.gz
# tar xfv culfw-1.55.tar

Nun können wir den CUL-Stick auch schon schon flashen. Das geht einfach mit folgendem Befehl:
# cd culfw-1.55/Devices/CUL
# sudo make usbprogram_v3

Danach hat die LED am CUL geblinkt und ich konnte meine IT Dosen steuern.

Hier der Auszug aus dem Logfile:

...
2016.03.22 21:02:11 3: Opening CUL_0 device /dev/ttyACM0
2016.03.22 21:02:11 3: Setting CUL_0 serial parameters to 9600,8,N,1
2016.03.22 21:02:11 3: CUL_0 device opened
2016.03.22 21:02:12 5: SW: V
2016.03.22 21:02:12 5: CUL/RAW (ReadAnswer): V 1.61 CUL433
2016.03.22 21:02:12 5: SW: ?
2016.03.22 21:02:12 5: CUL/RAW (ReadAnswer): ? (? is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2016.03.22 21:02:12 3: CUL_0: Possible commands: BbCFiAZEGMKUYRTVWXefmltux
2016.03.22 21:02:12 5: SW: X21
2016.03.22 21:02:12 5: SW: T01
2016.03.22 21:02:12 5: CUL/RAW (ReadAnswer): 1034
2016.03.22 21:02:12 5: GOT CUL fhtid: 1034
...


Und dies ist übrigens die Definition meiner Rollläden:

define Rollladen_Wohnen1 SOMFY 000001
attr Rollladen_Wohnen1 alias Rollladen Wohnzimmerfenster
attr Rollladen_Wohnen1 IODev CUL_0
attr Rollladen_Wohnen1 eventMap on:Runter off:Hoch stop:Stop go-my:My
attr Rollladen_Wohnen1 group Rollladen
attr Rollladen_Wohnen1 model somfyblinds
attr Rollladen_Wohnen1 room Wohnen
attr Rollladen_Wohnen1 webCmd Runter:Hoch:Stop:My

define Rollladen_Wohnen2 SOMFY 000002
attr Rollladen_Wohnen2 alias Rollladen Terrassentür
attr Rollladen_Wohnen2 IODev CUL_0
attr Rollladen_Wohnen2 eventMap on:Runter off:Hoch stop:Stop go-my:My
attr Rollladen_Wohnen2 group Rollladen
attr Rollladen_Wohnen2 model somfyblinds
attr Rollladen_Wohnen2 room Wohnen
attr Rollladen_Wohnen2 webCmd Runter:Hoch:Stop:My

Gruß
Lars

[viegener]

Ich bin mir nicht sicher was schief läuft, aber nach Deiner Beschreibung ist es ja so, dass der Befehl vom CUL korrekt erhalten und gesendet wird. Das Problem scheint erst danach aufzutreten. Als Vermutung würde ein Speicherüberschreiber naheliegen. Insbesondere da ja im Code der zurückkommt einzelne Bytes verdoppelt werden.

Also noch ein paar Fragen:
Ist es ein nanocul (sprich selbstgebaut oder etwas anderes)?

Die Firmware von culfw.de ist auch nicht mehr wirklich aktuell?
Ich würde aus sourceforge eine aktuellere Version nehmen https://sourceforge.net/p/culfw/code/HEAD/tarball

Als quickfix kannst Du vielleicht auch einfach den autocreate für SOMFY deaktivieren --> ignoreTypes
Das eigentlich Problem wird damit aber nicht gelöst

[mahura]

Ich setze den CUL433 von busware ein, siehe http://shop.busware.de/product_info.php/products_id/44?osCsid=227e74aadb489183955675433afc3078

ABER: nachdem ich letzte Nacht die 42 Seiten des Threads zur Implementirung des SOMFY-Protokols gelesen habe (*schwitz*) sollte als Ursache des Problems die Firmware des CUL feststehen - in diesem Thread wird von einigen Usern ebenfalls das von mir beobachtete Verhalten beschrieben und seit 10/2014 gab es hierzu Fixes in der Firmware die leider nicht auf der Webseite culfw.de zu finden sind. Das bedeutet eine Firmware 1.61 ist nicht gleich 1.61 (wie du schon sagst, auf sourceforge gibt es neuere. Jetzt muss ich nur noch herausfinden wie ich den letzten Stand flashe und hoffe dann den alten Fehler behoben zu haben.

Btw. Respekt vor der tollen Arbeit aller Beteiligten, aber der Versionsstand der Firmware muss zwingend identifizierbar sein.

Ich melde mich später nochmal mit meinem Ergebnis der Tests.

Viele Grüße
Lars

[mahura]

So, jetzt scheint alles zu passen 

Ich habe mir die Firmware 1.66 geflashed, hier der Auszug aus dem Logfile:

2016.03.23 11:33:03 4: WEB_192.168.0.23_54770 POST /fhem?cmd.Rollladen_Wohnen2=set%20Rollladen_Wohnen2%20Hoch&room=Wohnen&XHR=1&fw_id=151; BUFLEN:0
2016.03.23 11:33:03 5: Cmd: >set Rollladen_Wohnen2 Hoch<
2016.03.23 11:33:03 4: SOMFY_set: Rollladen_Wohnen2 -> entering with mode :send: cmd :off:  arg1 ::  pos :go-my:
2016.03.23 11:33:03 1: PERL WARNING: Argument "go-my" isn't numeric in addition (+) at ./FHEM/10_SOMFY.pm line 956.
2016.03.23 11:33:03 4: SOMFY_set: handled command off --> move :off:  newState :open:
2016.03.23 11:33:03 5: SOMFY_set: handled for drive/udpate:  updateState ::  drivet :0: updatet :0:
2016.03.23 11:33:03 4: SOMFY_sendCommand: Rollladen_Wohnen2 -> cmd :off:
2016.03.23 11:33:03 4: SOMFY set Rollladen_Wohnen2 off: sAB20000B000002
2016.03.23 11:33:03 5: SOMFY_sendCommand: Rollladen_Wohnen2 -> message :sAB20000B000002:
2016.03.23 11:33:03 5: CUL_0 sending YsAB20000B000002
2016.03.23 11:33:03 5: SW: YsAB20000B000002
2016.03.23 11:33:03 4: name: /fhem?cmd.Rollladen_Wohnen2=set%20Rollladen_Wohnen2%20Hoch&room=Wohnen&XHR=1&fw_id=151 / RL:20 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2016.03.23 11:33:04 5: CUL/RAW: /YsAB2A000B020000

2016.03.23 11:33:04 4: CUL_Parse: CUL_0 YsAB2A000B020000
2016.03.23 11:33:04 5: CUL_0 dispatch YsAB2A000B020000
2016.03.23 11:33:04 4: SOMFY Rollladen_Wohnen2 off
2016.03.23 11:33:04 5: Triggering Rollladen_Wohnen2 (1 changes)
2016.03.23 11:33:04 5: Notify loop for Rollladen_Wohnen2 parsestate: Hoch

Bis jetzt sind noch keine "Zombies" aufgetaucht...

Danke!!

Gruß
Lars

[viegener]

OK, sieht gut aus.
Johannes

[SirMortimer]

Hatte heute das selbe Problem (-> https://forum.fhem.de/index.php/topic,51875.msg436097.html#msg436097)

Mit der Firmware von sourceforge tauchen die Geistesgeräte nicht mehr auf.