Homematic wired

[Thorsten Pferdekaemper]

Meiner Meinung nach gab es eigentlich nie einen HMW_Sen_SC_12. Das Ding heißt entweder HMW-Sen-SC-12-DR oder HMW-Sen-SC-12-FM.

Mea culpa...
Da ist wohl doch was faul. Ich werd's reparieren.
Gruß,
   Thorsten

[Thorsten Pferdekaemper]

Hi,
mit Version 0.7.19 sollte der HMW-Sen-SC-12-DR und HMW-Sen-SC-12-FM wieder so behandelt werden wie in 0.6.3. D.h. die "-" werden zu "_" in FHEM.
Gruß,
   Thorsten

[exot]

Hallo Thorsten,
Danke Für deine Hilfe.

cd /opt/fhem/FHEM/lib/HM485/HM485d
chmod a+x HM485d.pl

Habe das eingearbeitet.

Code Auswählen Erweitern

2015.08.13 07:30:00 3: CUL_HM set RolloKueche on
2015.08.13 08:27:42 1: in SHUTDOWN
2015.08.13 08:27:42 1: in SHUTDOWN
2015.08.13 08:27:42 1: in SHUTDOWN
2015.08.13 08:27:42 1: in SHUTDOWN
2015.08.13 08:27:42 0: Server shutdown
2015.08.13 08:33:06 1: Including fhem.cfg
2015.08.13 08:33:06 3: telnetPort: port 7072 opened
2015.08.13 08:33:06 1: HMLAN_Parse: HMLAN1 new condition disconnected
2015.08.13 08:33:06 3: Opening HMLAN1 device 192.168.178.32:1000
2015.08.13 08:33:06 3: HMLAN1 device opened
2015.08.13 08:33:06 1: HMLAN_Parse: HMLAN1 new condition init
2015.08.13 08:33:07 3: HM485: HM485: Loading available device files
2015.08.13 08:33:07 3: HM485: =====================================
2015.08.13 08:33:07 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_central.pm
2015.08.13 08:33:07 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_generic.pm
2015.08.13 08:33:07 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_io12_sw14_dr.pm
2015.08.13 08:33:07 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_io12_sw7_dr.pm
2015.08.13 08:33:07 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_io12_sw7_dr_V3_02.pm
2015.08.13 08:33:07 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_io_12_fm.pm
2015.08.13 08:33:07 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_io_4_fm.pm
2015.08.13 08:33:07 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_io_4_fm_V3_02.pm
2015.08.13 08:33:07 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_io_sr_fm.pm
2015.08.13 08:33:07 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_lc_bl1_dr.pm
2015.08.13 08:33:07 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_lc_bl1_dr_V3_02.pm
2015.08.13 08:33:07 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_lc_dim1l_dr.pm
2015.08.13 08:33:07 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_lc_sw2_dr.pm
2015.08.13 08:33:07 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_lc_sw2_dr_V3_02.pm
2015.08.13 08:33:07 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_sen_sc_12_dr.pm
2015.08.13 08:33:07 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_virtual.pm
2015.08.13 08:33:07 3: WEB: port 8083 opened
2015.08.13 08:33:07 3: WEBphone: port 8084 opened
2015.08.13 08:33:07 3: WEBtablet: port 8085 opened
2015.08.13 08:33:07 2: eventTypes: loaded 556 events from ./log/eventTypes.txt
2015.08.13 08:33:08 2: fronthem: ipc listener opened at port 16384
2015.08.13 08:33:09 1: Including ./log/fhem.save
2015.08.13 08:33:09 1: statefile: Usage: setstate <name> <state>
where <name> is a single device name, a list separated by komma (,) or a regexp. See the devspec section in the commandref.html for details.

2015.08.13 08:33:09 1: in INITIALIZED
2015.08.13 08:33:09 1: in INITIALIZED
2015.08.13 08:33:09 1: in INITIALIZED
2015.08.13 08:33:09 1: in INITIALIZED
2015.08.13 08:33:09 1: usb create starting
2015.08.13 08:33:10 3: Probing CUL device /dev/ttyAMA0
2015.08.13 08:33:10 3: Probing TCM_ESP3 device /dev/ttyAMA0
2015.08.13 08:33:10 3: Probing FRM device /dev/ttyAMA0
2015.08.13 08:33:16 3: Probing TCM_ESP3 device /dev/ttyUSB0
2015.08.13 08:33:16 3: Probing TCM_ESP2 device /dev/ttyUSB0
2015.08.13 08:33:16 3: Probing FHZ device /dev/ttyUSB0
2015.08.13 08:33:16 3: Probing TRX device /dev/ttyUSB0
2015.08.13 08:33:17 3: Probing ZWDongle device /dev/ttyUSB0
2015.08.13 08:33:17 3: Probing FRM device /dev/ttyUSB0
2015.08.13 08:33:22 1: usb create end
2015.08.13 08:33:22 2: Error messages while initializing FHEM: statefile: Usage: setstate <name> <state> where <name> is a single device name, a list separated by komma (,) or a regexp. See the devspec section in the commandref.html for details.
2015.08.13 08:33:22 0: Featurelevel: 5.6
2015.08.13 08:33:22 0: Server started with 41 defined entities (version $Id: fhem.pl 9002 2015-07-29 05:46:10Z rudolfkoenig $, os linux, user fhem, pid 3088)
2015.08.13 08:33:23 3: hm485: Connect to HM485d delayed for 5 seconds
2015.08.13 08:33:23 3: hm485: Start HM485d with command line: ./FHEM/lib/HM485/HM485d/HM485d.pl --serialNumber SGW0123456 --device /dev/ttyUSB0 --localPort 2000
2015.08.13 08:33:23 3: hm485: HM485d was started with PID:  3101
2015.08.13 08:33:23 3: CUL_HM set RolloDiele statusRequest
2015.08.13 08:33:23 1: HMLAN_Parse: HMLAN1 new condition ok
2015.08.13 08:33:23 3: ipc fronthem:127.0.0.1:33851 (ws): ws alive with pid 3089
2015.08.13 08:33:24 3: CUL_HM set RolloKueche statusRequest
2015.08.13 08:33:28 3: Opening hm485 device localhost:2000
2015.08.13 08:33:28 3: hm485 device opened
2015.08.13 08:33:28 3: hm485: connected to device localhost:2000
2015.08.13 08:33:28 3: hm485: Lan Device Information
2015.08.13 08:33:28 3: hm485: Protocol-Version: 01
2015.08.13 08:33:28 3: hm485: Interface-Type: HMW-SOFT-GW
2015.08.13 08:33:28 3: hm485: Firmware-Version: 0.2.2
2015.08.13 08:33:28 3: hm485: Serial-Number: SGW0123456
2015.08.13 08:33:28 3: hm485: Initialize the interface
Jetzt ist Der Adapter gestartet:
< 2015.08.13 08:33:28 3: hm485 device opened >
Danke!
Leider muss ich jetzt etwas warten, bis der 12/7er Aktor kommt. Der Lieferant hat Urlaub.
Sobald das Teil eingetroffen ist melde ich mich.
Gruß Michael

[geri]

hi Thorsten!

Das sieht wirklich seltsam aus. Also die Taste dürfte ja nur funktionieren, wenn Du intern gepeert hast. Dann dürfte aber gar kein "set_toggle" im Event Log erscheinen. Kannst Du mal das Peering zeigen? Außerdem: Bist Du Dir ganz sicher, dass da nicht noch irgendwas in FHEM läuft? Irgendwelche notifies auf den state oder so?
...oder machst Du das ganze mit einem notify? Das wäre sowieso nicht so elegant.

ja ich mache es über notifys. zb:

Code Auswählen Erweitern

define eg_wohnzimmer_wohnzimmer notify HMW_IO_12_Sw7_11 set HMW_IO_12_Sw7_19 toggle grund ist fehlendes wissen über das interne peering.

Man sieht hier, dass mehrere "set toggle" gemacht werden. Ich kann mir nicht vorstellen, dass das von meinem Coding kommt. Wenn Dein notify tatsächlich so aussieht, wie Du geschrieben hast, dann triggert das für alle Events von taster_01, inklusive dem Battery-Event. Du musst das wahrscheinlich auf das Event "taster_01 taster_01_btn_01 Short" einschränken.

mit deinem vorschlag funktioniert das notify nicht mehr.

meine schreibweise der notifys erklärt auch das mehrfachen schalten.

gruss
Gerald

[geri]

hallo Thorsten!

ich habe meine notifys alle so umgeschrieben das sie nur mehr den kurzen tastendruck auswerten (:press_short:.*). somit läuft der HMW_IO_12_Sw7_DR mit der 0.7.20 wie vorher. gefühlt ist das system jetzt schneller in der reaktion.

auch die notifys vom HMW_Sen_SC_12_DR musste ich ändern, da state jetzt nicht mehr on/off ist sondern sensor_open/sensor_close.

beim HMW_IO_12_Sw14_DR habe ich bei den digitalen ausgängen ein problem beim toggle befehl festgestellt. setzte ich ein set_toogle ab geht der ausgang auf on aber bei jedem nachfolgenden set_toggle immer wieder bzw. bleibt auf on.
eventmonitor aufzeichnug:

Code Auswählen Erweitern

2015-08-13 10:58:32.565 HM485 HMW_IO_12_Sw14_02 set_toggle
2015-08-13 10:58:32.901 HM485 HMW_IO_12_Sw14_02 on
2015-08-13 10:58:40.515 HM485 HMW_IO_12_Sw14_02 set_toggle
2015-08-13 10:58:40.836 HM485 HMW_IO_12_Sw14_02 on

gruss
Gerald

[Thorsten Pferdekaemper]

grund ist fehlendes wissen über das interne peering.

Ich würde Dir das interne Peering dringend empfehlen, wenn Du sowieso nur ein Toggle bei einem Tastendruck brauchst. Dann funktioniert das ganze nämlich auch noch, wenn der FHEM-Rechner mal nicht funktioniert.

mit deinem vorschlag funktioniert das notify nicht mehr.

Ich bin auch nicht so der Held mit den RegExen. Aber Du hast es ja hinbekommen.

somit läuft der HMW_IO_12_Sw7_DR mit der 0.7.20 wie vorher. gefühlt ist das system jetzt schneller in der reaktion.

Das kann auch in Echt so sein, nicht nur gefühlt. 

auch die notifys vom HMW_Sen_SC_12_DR musste ich ändern, da state jetzt nicht mehr on/off ist sondern sensor_open/sensor_close.

Ich habe kein solches Device, daher konnte ich das nicht testen. Kannst Du mir mal einen Screenshot oder ein list von dem betreffenden Kanal schicken?

beim HMW_IO_12_Sw14_DR habe ich bei den digitalen ausgängen ein problem beim toggle befehl festgestellt. setzte ich ein set_toogle ab geht der ausgang auf on aber bei jedem nachfolgenden set_toggle immer wieder bzw. bleibt auf on.
eventmonitor aufzeichnug:

Code Auswählen Erweitern

2015-08-13 10:58:32.565 HM485 HMW_IO_12_Sw14_02 set_toggle
2015-08-13 10:58:32.901 HM485 HMW_IO_12_Sw14_02 on
2015-08-13 10:58:40.515 HM485 HMW_IO_12_Sw14_02 set_toggle
2015-08-13 10:58:40.836 HM485 HMW_IO_12_Sw14_02 on

Das ist natürlich blöd. Da scheint es unterschiede zwischen den Devices zu geben. Die anderen Devices mit switch-Ausgängen können "getoggelt" werden, wenn man ein 0xFF hinschickt. Das scheint beim HMW_IO_12_Sw14_DR nicht zu gehen. Ich habe aber in den Device-Files keinen Hinweis darauf gefunden. Das muss man dann wohl doch Gerätespezifisch implementieren. Ich werde versuchen, dass heute Abend zu machen.

Gruß,
   Thorsten

[geri]

hi Thorsten!

Ich habe kein solches Device, daher konnte ich das nicht testen. Kannst Du mir mal einen Screenshot oder ein list von dem betreffenden Kanal schicken?

ich hoffe das passt so?!?

Code Auswählen Erweitern

Internals:
   DEF        0000DA42_05
   FW_VERSION 3.01
   IODev
   MODEL      HMW_Sen_SC_12_DR
   NAME       HMW_Sen_SC_12_05
   NR         567
   STATE      sensor_closed
   TYPE       HM485
   chanNo     05
   device     HMW_Sen_SC_12
   Readings:
     2015-08-13 10:27:13   sensor          closed
     2015-08-13 10:27:13   state           sensor_closed
Attributes:
   firmwareVersion 3.01
   model      HMW_Sen_SC_12_DR
   room       HM485
   serialNr   LEQ0252304
   subType    sensor

gruss
Gerald

[Thorsten Pferdekaemper]

ich hoffe das passt so?!?

Ja, das ist auch das, was ich erwartet hatte. Meiner Meinung nach ist das so richtig. Die "Philosophie" dahinter ist folgendermaßen: Die Darstellung in FHEM soll sich möglichst nahe an das halten, was in den Device-Files (den XMLs von Homematic) festgelegt ist. Ansonsten haben wir zu viel gerätespezifisches Coding.
D.h. die Readings werden je nach Kanaldefinition im Device-File festgelegt. Da steht für den HMW_Sen_SC_12_DR/FM eben "sensor". Das Reading heißt also "sensor". In den notifies (und überall anders, wo man den Zustand braucht) sollte also das Reading "sensor" verwendet werden. Da es meiner Meinung nach FHEM-Standard ist, auch ein Reading "state" zu haben, baue ich aus dem letzten Reading, des Kanals, das vom Device gesendet wird, (im Wesentlichen) den Wert von "state" zusammen. Dabei wird der Reading-Name dem Zustand vorangestellt.
Eine Ausnahme ist, wenn das Reading laut Device-File "state" heißt. Dann bleibt state eben state.

Ich hoffe, dass wir das in der Art über alle Devices stabil halten können. Könntest Du Dein notify auf das Reading "sensor" umbauen?

Zu den Werten open/closed statt on/off: In der Gerätebeschreibung steht dazu eigentlich nur, dass es ein "boolean" ist. D.h. eigentlich müsste man true/false anzeigen. Das wäre meiner Meinung nach aber so gar nicht FHEM-like. on/off finde ich auch nicht ganz richtig. Ähnlich wie bei Rolloaktoren wüsste ich da nie, ob "on" jetzt auf oder zu bedeutet. Daher open/closed.

Gruß,
   Thorsten

[geri]

hi Thorsten!

Könntest Du Dein notify auf das Reading "sensor" umbauen?

klar habe ich bereits erledigt und läuft bestens.

Ich würde Dir das interne Peering dringend empfehlen, wenn Du sowieso nur ein Toggle bei einem Tastendruck brauchst. Dann funktioniert das ganze nämlich auch noch, wenn der FHEM-Rechner mal nicht funktioniert.

ja das sehe ich genauso und werde es auch für die zukunft so machen. nur eine frage hätte ich noch. wie kann ich das interen peering wieder lösen?

gruss
Gerald

[Thorsten Pferdekaemper]

ja das sehe ich genauso und werde es auch für die zukunft so machen. nur eine frage hätte ich noch. wie kann ich das interen peering wieder lösen?

Jedes Peering hat zwei Seiten: Sensor (Key, Taste o.ä.) und Aktor (Schalter, Rollo-Motor, Dimmer o.ä.). Gehe in den Sensor-Kanal des Peerings. Dort sollte es ein "set <kanal> unpeer ..." geben. Wenn Du "unpeer" im UI gewählt hast, dann solltest Du eine Auswahlliste der gepeerten Aktor-Kanäle bekommen. Den richtigen auswählen und "set" drücken.
Probleme gibt es momentan nur, wenn eine Seite des Peerings kaputt ist. Z.B. wenn Du eins der beteiligten Devices vom Bus genommen hast. Dann kann man das Peering momentan nicht mehr löschen. Honk arbeitet aber daran.

 

[geri]

hi Thorsten!

Dort sollte es ein "set <kanal> unpeer ..." geben. Wenn Du "unpeer" im UI gewählt hast, dann solltest Du eine Auswahlliste der gepeerten Aktor-Kanäle bekommen. Den richtigen auswählen und "set" drücken.

danke, mit etwas augenauf hätte ich das auch sehen/finden können. 

gruss
Gerald

[Thorsten Pferdekaemper]

hi Thorsten!danke, mit etwas augenauf hätte ich das auch sehen/finden können. 

Nicht weinen, ist jedem schon passiert...

[Thorsten Pferdekaemper]

beim HMW_IO_12_Sw14_DR habe ich bei den digitalen ausgängen ein problem beim toggle befehl festgestellt. setzte ich ein set_toogle ab geht der ausgang auf on aber bei jedem nachfolgenden set_toggle immer wieder bzw. bleibt auf on.

So, das ist mit Version 0.7.21 gefixt.
Das Problem ist, dass der HMW_IO_12_Sw14_DR eigentlich gar kein Toggle kann. D.h. FHEM muss entsprechend den Zustand abfragen und invertieren. Als Konsequenz wird beim HMW_IO_12_Sw14_DR bei toggle das Reading state auf "set_on" bzw "set_off" gesetzt und nicht auf "set_toggle".
Gruß,
   Thorsten

[ManfredC]

Hallo Manfred,


Die Version 0.6.3 von Thorsten ist da ein sicherer Einstieg. Damit läuft mein System auch.

ich habe heute mal ein Testsystem mit BBB, HMW-Lan Adapter, einem 12/7, einem HMW-IO-12-FM und der aktuellen dev-Version aufgesetzt. Einen 12/14 hab ich grad nur als nicht aufgebautem Bausatz, die anderen sind alle im Haus meines Sohnes verbaut.

Geht gut, wusste gar nicht dass man die Geräte direkt peeren kann. Geht das auch mit dem 12/14er? Wäre schön, da dann immer noch was geht wenn FHEM mal nicht läuft. Allerdings scheint man dann press_short und press_long nicht unterscheiden zu können. Oder irre ich hier?

Grüße,

Manfred

[Thorsten Pferdekaemper]

Geht gut, wusste gar nicht dass man die Geräte direkt peeren kann.

Klar, es hat nur gefehlt, dass man das in FHEM einstellen kann.

Geht das auch mit dem 12/14er?

Leider nicht. Das liegt aber nicht an der FHEM-Integration, sondern am 12/14er selbst. Auf der elv-Seite steht sogar:

Hinweis: Mit den Eingängen sind keine Direktverknüpfungen zu Aktoren möglich, stattdessen können zustandsabhängig in Programmen Aktionen ausgelöst werden.

Ich habe auch im Device-File keinen Anhaltspunkt dazu gefunden, auch nicht für die Ausgänge.

Allerdings scheint man dann press_short und press_long nicht unterscheiden zu können. Oder irre ich hier?

Man kann das sehr wohl unterscheiden. Wenn man ein Peering angelegt hat, dann kann man in der Kanal-Ansicht des Sensor-Kanals in FHEM "set ... peersettings ..." wählen. Dort kann man die Details zum Peering einstellen. Dazu gehört auch die Reaktion auf kurzen und langen Tastendruck etc.

Gruß,
   Thorsten