HM-MOD-Em-8: Nachrichten erneut senden nach Fehlübertragung?

[reen]

Hi,
ich habe festgestellt, dass mein HM-MOD-Em-8 wohl teilweise ausgelöste Signale nicht richtig an fhem übermittelt hat.
Habe an dem Modul 2 Eingänge in Benutzung. Einer als Sensor-Modus um die Betriebszeit eines Ölbrenners zu loggen, und einen als Trigger-Modus, welcher die Wasseruhr überprüft.
Zwischen meiner Wasseruhr und der Anzeige in FHEM gibt es nun eine Differenz (Wasseruhr hat mehr als FHEM). Dies kann kaum an nicht erkannten Signalen der Wasseruhr liegen, die sind sehr zuverlässig.
Das Modul hat auch guten Empfang und wird nicht bewegt.

Könnte es sein dass die Übermittlung manchmal nicht funktioniert weil vielleicht zufällig beide Kanäle übermitteln wollen?

Kann man das Modul dazu bringen zu prüfen ob die Übertragung fehlerhaft war und dann die Nachricht erneut senden lassen?


hier noch kurz ein List des entsprechenden Kanals:

Code Auswählen Erweitern

Internals:
   DEF        3D650608
   NAME       hk_hmSM_Wasseruhr
   NOTIFYDEV  global
   NR         102
   NTFY_ORDER 50-hk_hmSM_Wasseruhr
   STATE      119.645 qm
   TYPE       CUL_HM
   chanNo     08
   device     hk_hmSM
   Readings:
     2016-11-01 19:58:47   R-sign          off
     2016-11-04 17:09:56   RegL_01.        04:10 08:00 20:60 23:05 30:03 92:23 00:00
     2016-11-13 15:29:15   state           Short (to HMLAN1)
     2016-11-13 15:29:15   trigDst_323CAD  noConfig
     2016-11-13 15:29:15   trigger         Short_21
     2016-11-13 15:29:15   trigger_cnt     21
     2016-11-13 15:29:15   verbrauch       917
     2016-11-13 15:29:15   wasseruhr       119.645
     2016-11-13 15:29:15   wasseruhrLiterOffset 118728
   Helper:
     BNO        21
     BNOCNT     1
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Role:
       chn        1
Attributes:
   model      HM-MOD-Em-8
   peerIDs    00000000,
   room       Heizkeller
   stateFormat {sprintf("%.3f"." qm",ReadingsVal('hk_hmSM_Wasseruhr','wasseruhr',0));}

   userReadings verbrauch:trigger_cnt.* {ReadingsVal("hk_hmSM_Wasseruhr", "verbrauch", 0)+1;}, wasseruhrLiterOffset { 118728;}, wasseruhr:trigger_cnt.* {(ReadingsVal("hk_hmSM_Wasseruhr", "verbrauch", 0)+ReadingsVal("hk_hmSM_Wasseruhr", "wasseruhrLiterOffset", 0))/1000;}
Viele Grüße
reen

[martinp876]

das Device hat je Kanal ein "transmitTryMax"  . Eine Kollision innerhalb des Devices sollte das Device selbst kontrollieren. Ein Kanal sendet nicht, senden wird immer das "Device". Das wäre ein böses FW-foul.
Allerdings kann es eine Kollision "in der Luft" geben. Dafür gibt es ein retransmit.

Da aber dein KAnal nicht gepeer ist könnte es sein, dass es kein ACK erwartet. Also wird es auch kein retransmit geben.
Peere das Device mit einem Kanal der VCCU. Suche dir einen aus deiner Wahl- das macht am meisten Sinn.

[reen]

Danke Martin, da bin ich noch nicht ganz durchgestiegen.

Ich habe ein HM_Lan-Adapter, mit dem ich direkt paire, ohne eine VCCU.
Gepairt ist das HM-MOD-EM-8 also direkt über den Lanadapter.

list:

Code Auswählen Erweitern

Internals:
   DEF        3D6506
   HMLAN1_MSGCNT 536
   HMLAN1_RAWMSG E3D6506,0000,10BB7EB3,FF,FFD0,DFA2413D6506323CAD01BFC8
   HMLAN1_RSSI -48
   HMLAN1_TIME 2016-11-14 14:23:31
   IODev      HMLAN1
   LASTInputDev HMLAN1
   MSGCNT     536
   NAME       hk_hmSM
   NOTIFYDEV  global
   NR         99
   NTFY_ORDER 50-hk_hmSM
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 hk_hmSM_Brenner
   channel_02 hk_hmSM_Btn_02
   channel_03 hk_hmSM_Btn_03
   channel_04 hk_hmSM_Btn_04
   channel_05 hk_hmSM_Btn_05
   channel_06 hk_hmSM_Btn_06
   channel_07 hk_hmSM_Btn_07
   channel_08 hk_hmSM_Wasseruhr
   lastMsg    No:DF - t:41 s:3D6506 d:323CAD 01BFC8
   protLastRcv 2016-11-14 14:23:31
   protSnd    536 last_at:2016-11-14 14:23:31
   protState  CMDs_done
   rssi_at_HMLAN1 avg:-48.3 min:-50 max:-47 lst:-48 cnt:536
   Readings:
     2016-11-04 17:14:51   CommandAccepted yes
     2016-11-04 17:13:13   D-firmware      1.1
     2016-11-04 17:13:13   D-serialNr      MEQ0782171
     2016-11-04 17:09:48   PairedTo        0x323CAD
     2016-11-01 19:58:39   R-pairCentral   0x323CAD
     2016-11-04 17:09:48   RegL_00.        02:01 05:00 0A:32 0B:3C 0C:AD 12:00 14:03 18:00  00:00
     2016-11-08 19:02:27   alive           yes
     2016-11-14 14:23:31   battery         ok
     2016-11-08 19:02:27   powerOn         2016-11-08 19:02:27
     2016-11-08 19:02:27   recentStateType info
     2016-11-14 14:23:31   state           CMDs_done
   Helper:
     HM_CMDNR   223
     mId        00D9
     rxType     16
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +3D6506,00,00,00
       nextSend   1479129811.69363
       prefIO
       rxt        2
       vccu
       p:
         3D6506
         00
         00
         00
     Mrssi:
       mNo        DF
       Io:
         HMLAN1     -46
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       dev        1
     Rpt:
       IO         HMLAN1
       flg        A
       ts         1479129811.6102
       ack:
         HASH(0x3392830)
         DF8002323CAD3D650600
     Rssi:
       At_hmlan1:
         avg        -48.3059701492538
         cnt        536
         lst        -48
         max        -47
         min        -50
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


Mit dem peeren habe ich noch keine Erfahrungen, und daher gerade mal das wiki durchschaut.
Laut dem wiki Eintrag ist das peeren von Kanälen dazu da, dass die Kanäle auch ohne Zentrale kommunizieren können.
So ein peeren mit der "Zentrale" erscheint mir dann erstmal unlogisch? 
Wenn du sagt, es sendet nur das device, welches ich ja eh schon gepairt habe, denke ich erstmal, das müsste reichen.

Aber ich glaub das natürlich und würde es gerne besser verstehen.
Geht das ohne VCCU dann hiermit:

Code Auswählen Erweitern

set <actChan> peerIODev <IO> <chan> [set|unset] ?
Muss der <chan> vorher noch definiert werden, und wie bekommt das HM-MOD-EM-8 dieses peering mit?

[Otto123]

Hi,

So ein peeren mit der "Zentrale" erscheint mir dann erstmal unlogisch? 

Hier geht es um eine spezielle Eigenschaft:
Ein nicht gepeerter Kanal sendet einfach eine Nachricht, ihm ist egal ob es jemand hört oder nicht. Eine Telegramm und fertig.
Ein gepeerter Kanal erwartet eine Quittung vom Empfänger, kommt die nicht versucht er es erneut. Bis zu dreimal.
Wenn man einen Taster z.B. mit einem Virtuellen Aktor peert, erhält der Taster eine Quittung von der Zentrale und seine LED blinkt grün ansonsten nur gelb.

Würde ein Telegramm verloren gehen, würde der EM-08 einer Wiederholung machen.

Gruß Otto

[reen]

Aha, das machts schon etwas klarer, danke Otto!

Dann würde ich wie folgt vorgwehen:
ausführen:

Code Auswählen Erweitern

set 1 peerIODev HMLAN1 hk_hmSM_Wasseruhr
HM-MOD-EM-8 aufwecken, damit es die config übermittelt bekommt.
Fertig!?

1 steht dann für den Kanal 1 der Zentrale wenn ich das richtig verstanden habe.
Muss man den erst anlegen oder prüfen ob da schon etwas gepeert ist?

Edit:
vielleicht könnte mir ja jemand kurz ein tipp geben, ob das geschilderte vorgehen und der Befehl so passen, oder ob ich auf dem Holzweg bin. Ein entsprechendes komplettes Beispiel habe ich nicht gefunden.

[Otto123]

Hallo reen,

wie das mit dem IOdev geht, weiß ich nicht. betateilchen hat das glaube ich mal beschrieben.
Hier ist beschrieben wie man virtuelle Kanäle erzeugt.
Ein virtueller Kanal ist von der Sache her wie ein universelles HM Gerät.
gepeert  wird mit dem Kommando peerChan, das findest Du im set Befehl in der Oberfläche des Kanal Deines EM-8. Als Aktor wird ein virtueller Kanal angegeben, den Namen findest Du bei der VCCU. Hinter peerChan musst Du noch Parameter angeben:
0 <Name des Virtuellen Kanals> single set both.

Hier habe ich das peering für meinen Garagenantrieb beschrieben. Falls Du noch ein paar praktische Ideen brauchst 

Gruß Otto

[reen]

Hi Otto,
danke für die Hilfe!
Eine VCCU habe ich nicht, daher dachte ich, dass der peerIODev vielleicht passt.
Wäre es möglich eine VCCU anzulegen, und diese dann nur für das peeren zu verwenden, auch wenn diese eine andere hmid besitzt? - dann würde ich dafür eine anlegen. (ich würde nur ungern eine VCCU mit dem Lan-Adapter verwenden.)

0 <Name des Virtuellen Kanals> single set both.

Was bedeutet denn die "0" und das "both"?
...und gibt es eigentlich eine Möglichkeit die Channels der VCCU oder des IODevs anzuzeigen?

[Otto123]

(ich würde nur ungern eine VCCU mit dem Lan-Adapter verwenden.)

Verstehe ich nicht, aber egal.
Du kannst auch nur einen virtuellen Aktor anlegen.
Alles wichtige dazu steht in der commandref, auch die Beschreibung der Befehle und Optionen zu peerChan.
Die 0 kann ich Dir nicht genau erklären, die ist so  both bedeutet, dass beide Seiten mit einem Kommando konfiguriert werden.
Siehe auch diesen Thread.
Ein IODev hat keine Channel, zumindest nicht, dass ich wüsste. Die Channels der VCCU siehst Du einfach in der Definition. Wie bei jedem HM Gerät.

Gruß Otto

[reen]

ja, bisher habe ich eine VCCU eben nicht benötigt, aber jetzt ist wohl der Zeitpunkt gekommen, dass ich sie brauche, also hab ich sie angelegt, danke soweit Otto.

[frank]

ich denke, dass du zusätzlich auch den trigger überwachen könntest.

Code Auswählen Erweitern

2016-11-13 15:29:15   trigger_cnt     21
bei jedem zählimpuls müsste der counter um 1 hochzählen. gehen messages verloren, kannst du sie sogar "rekonstruieren". der zähler sollte nach 255 wieder bei 0 beginnen.

[reen]

Also ich habe jetzt den Kanal gepeert:
Sende-Modul kanal List:

Code Auswählen Erweitern

Internals:
   DEF        3D650608
   NAME       hk_hmSM_Wasseruhr
   NOTIFYDEV  global
   NR         102
   NTFY_ORDER 50-hk_hmSM_Wasseruhr
   STATE      V-Heute: 139 Liter - Wasseruhr: 120.106 qm
   TYPE       CUL_HM
   chanNo     08
   device     hk_hmSM
   Readings:
     2016-11-15 22:08:09   R-VCCU_chan1_Wasseruhr-expectAES set_off
     2016-11-15 22:08:09   R-VCCU_chan1_Wasseruhr-peerNeedsBurst set_off
     2016-11-01 19:58:47   R-sign          off
     2016-11-04 17:09:56   RegL_01.        04:10 08:00 20:60 23:05 30:03 92:23 00:00
     2016-11-15 22:13:02   state           Short (to VCCU)
     2016-11-14 22:38:21   trigDst_323CAD  noConfig
     2016-11-15 22:13:02   trigger         Short_166
     2016-11-15 22:13:02   trigger_cnt     166
     2016-11-15 22:13:02   verbrauch_today 139
     2016-11-15 22:13:02   verbrauch_total 1378
     2016-11-15 22:13:02   wasseruhr       120.106
     2016-11-15 22:13:02   wasseruhrLiterOffset 118728
     2016-11-14 23:59:00   z_wasseruhr_delta_d 119.967
     2016-11-14 23:59:00   z_wasseruhr_last_d 119.967
   Helper:
     BNO        166
     BNOCNT     1
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Role:
       chn        1
     Shadowreg:
       RegL_04.VCCU_chan1_Wasseruhr  01:00
Attributes:
   model      HM-MOD-Em-8
   peerIDs    00000000,
   room       Heizkeller
   stateFormat {sprintf("V-Heute: %.0f Liter - Wasseruhr: %.3f qm",
ReadingsVal('hk_hmSM_Wasseruhr','verbrauch_today',0),
ReadingsVal('hk_hmSM_Wasseruhr','wasseruhr',0));}
   userReadings verbrauch_total:trigger_cnt.* {ReadingsVal("hk_hmSM_Wasseruhr", "verbrauch_total", 0)+1;},
verbrauch_today:trigger_cnt.* {ReadingsVal("hk_hmSM_Wasseruhr", "verbrauch_today", 0)+1;},
wasseruhrLiterOffset { 118728;},
wasseruhr:trigger_cnt.* {(ReadingsVal("hk_hmSM_Wasseruhr", "verbrauch_total", 0)+ReadingsVal("hk_hmSM_Wasseruhr", "wasseruhrLiterOffset", 0))/1000;}


VCCU-Kanal list:

Code Auswählen Erweitern

Internals:
   DEF        323CAD01
   NAME       VCCU_chan1_Wasseruhr
   NOTIFYDEV  global
   NR         112
   NTFY_ORDER 50-VCCU_Btn1
   STATE      ???
   TYPE       CUL_HM
   chanNo     01
   device     VCCU
   peerList   hk_hmSM_Wasseruhr,
   Readings:
     2016-11-15 22:08:09   peerList        hk_hmSM_Wasseruhr,
     2016-11-15 22:14:23   state           set_press short
   Helper:
     count      1
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Role:
       chn        1
       vrt        1
Attributes:
   model      CCU-FHEM
   peerIDs    3D650608,
   webCmd     press short:press long

Woran erkenne ich nun, ob das peering in Ordnung ist?
Kann ich nun davon ausgehen, dass ich nach wie vor mit dem Sende-Modul Kanal hk_hmSM_Wasseruhr arbeiten kann und dass eventuelle Fehlübertragungen erneut gesendet werden?

[Otto123]

Peering ist nicht in Ordnung beim Kanal vom EM-8 ->   peerIDs    00000000,

Beim virtuellen Kanal steht er drin.

Du musst nach dem peerChan beim EM-8 die Übertragung triggern. Configtaste drücken oder Kanal triggern.

wie sah den peerChan Befehl aus?

Gruß Otto

[Pfriemler]

Also ich habe jetzt den Kanal gepeert: ...
Woran erkenne ich nun, ob das peering in Ordnung ist?

Daran dass das Internal "peerList" beim fraglichen HM-MOD-EM-8-Kanal nicht gesetzt ist. Checke das mit getConfig. Wiederhole ggf. das Peering. Triggere das Modul per Taste oder Statusänderung, damit es das Peering übernimmt.

edit: Dam'nd, Otto war wieder schneller ...

[reen]

der Befehl war:

Code Auswählen Erweitern

set hk_hmSM_Wasseruhr 0 VCCU_chan1_Wasseruhr single set both

sorry, hatte die configtaste vor dem absenden gedrückt, nicht nochmal danach.
nun:

Code Auswählen Erweitern

Internals:
   DEF        3D650608
   NAME       hk_hmSM_Wasseruhr
   NOTIFYDEV  global
   NR         102
   NTFY_ORDER 50-hk_hmSM_Wasseruhr
   STATE      V-Heute: 140 Liter - Wasseruhr: 120.107 qm
   TYPE       CUL_HM
   chanNo     08
   device     hk_hmSM
   peerList   VCCU_chan1_Wasseruhr,
   Readings:
     2016-11-15 22:44:03   R-VCCU_chan1_Wasseruhr-expectAES off
     2016-11-15 22:44:03   R-VCCU_chan1_Wasseruhr-peerNeedsBurst off
     2016-11-01 19:58:47   R-sign          off
     2016-11-15 22:44:02   RegL_01.          04:10 08:00 20:60 23:05 30:03 92:23 00:00
     2016-11-15 22:44:03   RegL_04.VCCU_chan1_Wasseruhr   01:00 00:00
     2016-11-15 22:44:03   peerList        VCCU_chan1_Wasseruhr,
     2016-11-15 22:31:28   state           Short (to VCCU)
     2016-11-14 22:38:21   trigDst_323CAD  noConfig
     2016-11-15 22:31:28   trigger         Short_167
     2016-11-15 22:31:28   trigger_cnt     167
     2016-11-15 22:31:28   verbrauch_today 140
     2016-11-15 22:31:28   verbrauch_total 1379
     2016-11-15 22:31:28   wasseruhr       120.107
     2016-11-15 22:44:03   wasseruhrLiterOffset 118728
     2016-11-14 23:59:00   z_wasseruhr_delta_d 119.967
     2016-11-14 23:59:00   z_wasseruhr_last_d 119.967
   Helper:
     BNO        167
     BNOCNT     1
     peerIDsRaw ,323CAD01,00000000
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Role:
       chn        1
     Shadowreg:
Attributes:
   model      HM-MOD-Em-8
   peerIDs    00000000,323CAD01,
   room       Heizkeller
   stateFormat {sprintf("V-Heute: %.0f Liter - Wasseruhr: %.3f qm",
ReadingsVal('hk_hmSM_Wasseruhr','verbrauch_today',0),
ReadingsVal('hk_hmSM_Wasseruhr','wasseruhr',0));}
   userReadings verbrauch_total:trigger_cnt.* {ReadingsVal("hk_hmSM_Wasseruhr", "verbrauch_total", 0)+1;},
verbrauch_today:trigger_cnt.* {ReadingsVal("hk_hmSM_Wasseruhr", "verbrauch_today", 0)+1;},
wasseruhrLiterOffset { 118728;},
wasseruhr:trigger_cnt.* {(ReadingsVal("hk_hmSM_Wasseruhr", "verbrauch_total", 0)+ReadingsVal("hk_hmSM_Wasseruhr", "wasseruhrLiterOffset", 0))/1000;}

[Pfriemler]

So. Das Modul sollte jetzt die Sendungen quittiert bekommen (grüne Status-LED).
Das Register "transmDevTryMax" (im Gerät-Def) kann ggf. von 3 auf 10 erhöht werden - die maximale Sendeversuche bis zu einer erfolgreichen Quittung (dann rot)