HM-MOD-EM-8 - Zwei Kanalzustände gleichzeitig übermitteln?

Begonnen von reen, 03 November 2016, 23:18:08

Vorheriges Thema - Nächstes Thema

reen

Hi,

ich habe ein HM-MOD-EM-8 im Einsatz, an welchen ich zwei Kanäle in Verwendung habe.

Internals:
   DEF        3D6506
   HMLAN1_MSGCNT 9172
   HMLAN1_RAWMSG E3D6506,0000,D9D3F4DB,FF,FFD2,0CA2403D6506323CAD0819
   HMLAN1_RSSI -46
   HMLAN1_TIME 2016-11-03 22:33:47
   IODev      HMLAN1
   LASTInputDev HMLAN1
   MSGCNT     9172
   NAME       hk_hmSM
   NOTIFYDEV  global
   NR         99
   NTFY_ORDER 50-hk_hmSM
   STATE      hk_hmSM_Wasseruhr Short
   TYPE       CUL_HM
   channel_01 hk_hmSM_Brenner
   channel_08 hk_hmSM_Wasseruhr
   lastMsg    No:0C - t:40 s:3D6506 d:323CAD 0819
   protLastRcv 2016-11-03 22:33:47
   protSnd    38 last_at:2016-11-03 22:33:47
   protState  CMDs_done
   rssi_at_HMLAN1 avg:-46.03 min:-68 max:-45 lst:-46 cnt:9172
   Readings:
     2016-10-29 13:56:24   CommandAccepted yes
     2016-11-02 21:05:21   D-firmware      1.1
     2016-11-02 21:05:21   D-serialNr      MEQ0782171
     2016-11-02 21:05:22   PairedTo        0x323CAD
     2016-11-01 19:58:39   R-pairCentral   0x323CAD
     2016-11-02 21:05:22   RegL_00.        02:01 05:00 0A:32 0B:3C 0C:AD 12:00 14:03 18:00  00:00
     2016-11-03 18:38:44   alive           yes
     2016-11-03 22:33:47   battery         ok
     2016-11-03 18:38:44   powerOn         2016-11-03 18:38:44
     2016-11-03 18:38:44   recentStateType info
     2016-11-03 22:33:47   state           hk_hmSM_Wasseruhr Short
   Helper:
     HM_CMDNR   12
     PONtest    0
     mId        00D9
     rxType     16
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +3D6506,00,00,00
       nextSend   1478208827.88954
       prefIO
       rxt        2
       vccu
       p:
         3D6506
         00
         00
         00
     Mrssi:
       mNo        0C
       Io:
         HMLAN1     -44
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf   00
       qReqStat
     Role:
       dev        1
     Rpt:
       IO         HMLAN1
       flg        A
       ts         1478208827.80559
       ack:
         HASH(0x1db5e90)
         0C8002323CAD3D650600
     Rssi:
       At_hmlan1:
         avg        -46.0396860008723
         cnt        9172
         lst        -46
         max        -45
         min        -68
Attributes:
   IODev      HMLAN1
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.1
   model      HM-MOD-Em-8
   room       CUL_HM
   serialNr   MEQ0782171
   subType    remote
   webCmd     getConfig:clear msgEvents


Kanal1: Wird verwendet um ein Schaltzustand eines Ölbrenners zu übermitteln. -> Long-Auslösungen
Kanal8: Wird verwendet um an eine Wasseruhr abzufragen (1 Umdrehung / Literr = 1 Puls). -> Short-Auslösungen

Wenn der Brenner nun läuft, ist auf Kanal1 die Long-Auslösung aktiv - das sehe ich dann auch im FHEM, state des Kanal1 zählt kontinuierlich hoch! (btw: kann dass nicht kritisch werden, bezüglich erlaubtem Sendeanteil, falls hier zu lange long ausgelöst sein sollte?) 
Wenn nun während des aktivem Long-Zustands auf Kanal1 ein Short-Puls der Wasseruhr auf Kanal8 stattfindet, wird dieser nicht an mein FHEM übermittelt.

Ist das Normal?
Gibt es da eine Möglichkeit  das besser zu machen, zB. dass beim Long-Zustand nur "Start des Long Signals" und "Stop des Langsignals" übermittelt wird?

Irgendwie macht dies verhalten das Modul doch nur halb so praktikabel, oder?

Bin für jede Info dankbar :)

BTW: Gibt es für die HomeMatic Geräte eigentlich auch solche Übersichten bezüglich Configparametern, wie es zB bei z-Wave Geräten gibt?

Pfriemler

Solange ein Kanal ein Long-Event sendet, werden keine anderen Zustände übermittelt.

Es ist aber weder hilfreich noch sinnvoll, einen Schaltzustand als Long-Dauerfeuer zu übermitteln, wie das Modul das im Default tut (Modus "button"). Dafür kann man das Modul kanalweise in die Schaltzustandserkennung umschalten ("sensor"), wo jeder Zustandswechsel als ein Telegramm übermittelt wird. Genau danach hast Du ja gefragt.
Hier können sich dann sogar mehrere Kanäle zeitgleich ändern, das Modul entzerrt die Infos automatisch und sendet sie seriell.
Im Wiki steht die Umstellung beschrieben.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

reen

Danke Pfriemler,

für mich war das aktuelle Verhaltung auch schon eine Art "Sensor-Modus", daher dachte ich das wäre ok soweit, aber jetzt bin ich ja schlauer. ;)
Dann werde ich das später mal angehen.

Was ich mir dabei aber gerade vorstelle:
Wenn ich im richtigen Sensor-Modus also nur die Start/Stop Signale bekomme und auf das ganze eine Plot-Auswertung mache, dann würde ich als Diagramm ja eher eine "Dreiecksform" anstatt einer "Rechtecksform" (was ja eigentlich korrekt wäre) erhalten, oder?
Gibt es da einen Trick um das richtig darzustellen? 


frank

FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Otto123

Im triggerMode sensor bekommst Du den Status open oder closed zurück.

Der bleibt eindeutig auch im Plot, wenn ich dein Problem richtig verstanden habe.

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Pfriemler

Reen meint, dass bei einzelnen Schaltpunkten im Plot die Linien default direkt verbunden werden,  was "Dreiecke" ergibt. Frank hat als Lösung im SVG-Editor den Diagrammtyp "steps" vorgeschlagen. Damit ist eigentlich alles klar?

geht nich gips nich

"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

reen

#6
Richtig verstanden, das war die Lösung. :)

Eine kurze andere Frage:
Ich habe nun den Channel per triggerModus auf sensor umgeschaltet - seit dem erscheinen in der FileLog des Moduls keine Einträge mehr, die den entsprechenden Channelnamen enthalten. Somit kann ich den Channel nichtmehr per regex aus der FileLog auslesen. - Versteht ihr was ich meine?

Letztes Event für das Reading des Channels:
trigger_cnt      171      2016-11-06 20:25:56

und hier der Auszug aus der FileLog des Sendemoduls zu dem Zeitpunkt:
2016-11-06_20:25:56 hk_hmSM battery: ok
2016-11-06_20:25:56 hk_hmSM CMDs_done


Edit: Der Channel heisst eigentlich "hk_hmSM_Brenner"


Ist das ein bekanntes Verhalten? und wie kann man dem denn entgegen wirken?

Otto123

Also bei mir werden die Channels im Modul-Filelog auch nicht geloggt. Das musst Du extra tun.
Hast Du die Channels umbenannt? Dann musst Du fürs logging neustarten, zumindest war das bei mir immer so.

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Pfriemler

#8
Sicher, dass die regex des FileLog noch auf die neuen Events passt? Poste mal die Einstellungen. Insbesondere falls Du den Channel des Brennerkanals umbenannt hast.
Eigentliche Ursache dürfte aber sein, dass es im Modus "sensor" ein von Beginn abweichendes Verhalten mit den Logeinträgen gibt. Ich hatte das hier schon mal zu (er)klären versucht.

Füge einfach ein passendes Regex zum zum FileLog hinzu und dann passt es. Suche dort im Regex-Assistenten in der Dropdownliste nach "hk_hmSM-Brenner" und als Event "contact:.*" Dann werden die Events "contact: closed" und "contact: opened" geloggt und können im SVG ausgewertet werden. Wie Du die richtige Spalte/das richtige Element der geloggten Zeile auswählst, müsstest Du schon wissen, oder?

Nachtrag: @Otto: Exakt Deiner Meinung :-)

und an reen: Überlege, ob Du nicht einfach ein anderes Log erstellst, was wirklich nur die wichtigen Events beinhaltet. Die ständigen "battery: ok" etc zu loggen, wie es das per autocreate angelegte FileLog tut, ist aus meiner Sicht sinnfrei. Ich fasse meist Events unterschiedlichster Geräte, aber identischer Kategorie zusammen (etwa alle Außentemperaturen, Innentemperaturen, Meldungen der Alarmanlage, ...)
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

reen

#9
Ja, ich habe die Channels umbenannt und seither auch schon das System neugestartet.

@pfriemler: So hatte ich das auch ungefähr gedacht, wollte für den Channel ein eigenes FileLog-Modul anlegen, aber da keine Einträge mit dem Channelnamen im FileLog der Sendeeinheit erzeugt werden, kann ich diese ja leider auch nicht per regex abfangen.
Wie ich das richtige Element einer entsprechenden Zeile im Log auswähle, ist mir bekannt, ja. ;)

2016-11-06_20:25:56 hk_hmSM CMDs_done Kann sich das vent für den Brennerchannel dann dahinter verstecken?

btw: ein Channel, der sich noch im Switch Modus befindet, erzeugt im FileLog-Modul der Sendereinheit jedoch einträge mit dem korrekten Channelnamen.

Edit: und bevor ich den Brenner-Channel in sensor Modus umgestellt habe, wurden auch von diesem Channel Einträge mit dem Brenner-Channelnamen erzeugt.

@otto: du siehst also keine Einträge mit Channelnamen in der LogFile der Sendeeinheit, kannst sie aber trotzdem per regex, rausziehn?

Pfriemler

Ein Beispiel von mir:
Mein eines EM-8 heißt 8BattSensor2 und seine FileLog-Definition lautet
./log/8BattSensor2-%Y.log 8BattSensor2
.
Alle Kanalnamen haben nichts mehr mit "8BattSensor2" zu tun, folglich erscheinen im FileLog nur noch die vom Gerät gesendeten Events. Natürlich senden die Kanäle selbst Events, aber dafür musst Du die Eventfilter des FileLogs anpassen wie beschrieben.
Der von mir beschriebene Effekt (nachlesbar im verlinkten Fred) bezieht sich auf die Eigenheit, dass namentlich die als sensor eingestellten Kanäle leicht abweichende Texte senden, die vom autocreate-FileLog nicht mehr erfasst werden - exakt Dein Problem.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

Otto123

Zitat von: reen am 06 November 2016, 21:27:39
@otto: du siehst also keine Einträge mit Channelnamen in der LogFile der Sendeeinheit, kannst sie aber trotzdem per regex, rausziehn?
Selbstverständlich! Mein Gerät heißt RC81 Mein Channel heißt RC81_1_TorOben der ist im jedem FileLog per  Regexp parts auswählbar.

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

reen

#12
@ Pfriemler: Danke, habe mir deinen Post im Link durchgelesen, und jetzt auch verstanden. :)

Alles korrekt und funktioniert bei mir nun auch.

Danke euch beiden treuen Helfern für die Geduld!