Peering/Pairing Fehler bei HM-CC-VD

Begonnen von smoneck, 30 Oktober 2017, 13:18:19

Vorheriges Thema - Nächstes Thema

smoneck

Hallo!

Irgendwo laeuft bei uns was schief ... Ausnahmslos alle HM-CC-VDs werfen folgende Fehler in `get hm configCheck`:

peer list incomplete. Use getConfig to read it.
    incomplete: Thermostat_HI1_A1:
    incomplete: Thermostat_HI1_A2:
    ...

peer not verified. Check that peer is set on both sides
    Thermostat_HI1_Climate p:Thermostat_HI1_A1
    Thermostat_HI1_Climate p:Thermostat_HI1_A2
    ...


Unser Prozedere ist:

  • HM-CC-VDs an HM-CC-TC anlernen
  • HM-CC-TC anlernen mittels `set HMLAN hmPairForSec X`
  • Dann wird die Konfig von einem Skript gesetzt. Die Rohform lasse ich im Anhang.

Fehlt da irgendetwas oder kann ich die Meldungen einfach ignorieren? Generell komme keine Befehle bei den HM-CC-VDs an. Lediglich das Stellen ueber die HM-CC-TC funktioniert. Keine Ahnung, ob das normal ist, damit koennen wir jedoch leben.


Vielen Dank!



Anhang

HM-CC-VD
#
## ------------- <DEVICENAME> in <ROOM> --------------
#

define <DEVICENAME> <CLASS> <HMID>
attr <DEVICENAME> IODev <HMLAN>
attr <DEVICENAME> actCycle 000:20
attr <DEVICENAME> actStatus alive
attr <DEVICENAME> autoReadReg 4_reqStatus
attr <DEVICENAME> expert 2_raw
attr <DEVICENAME> firmware <FIRMWARE>
attr <DEVICENAME> model HM-CC-VD
attr <DEVICENAME> room <ROOM>
attr <DEVICENAME> serialNr <SERIAL>
attr <DEVICENAME> subType thermostat
attr <DEVICENAME> webCmd getConfig:clear msgEvents:burstXmit
attr <DEVICENAME> event-on-change-reading .*

define FileLog_<DEVICENAME> FileLog ./log/<DEVICENAME>-%Y.log <DEVICENAME>
attr FileLog_<DEVICENAME> logtype text
attr FileLog_<DEVICENAME> room <ROOM>

#--------------- End of <DEVICENAME> --------------


HM-CC-TC
#
## ------------- <DEVICENAME> in <ROOM> --------------
#

define <DEVICENAME> <CLASS> <HMID>
attr <DEVICENAME> IODev <HMLAN>
attr <DEVICENAME> actCycle 000:10
attr <DEVICENAME> actStatus alive
attr <DEVICENAME> autoReadReg 4_reqStatus
attr <DEVICENAME> expert 2_raw
attr <DEVICENAME> firmware <FIRMWARE>
attr <DEVICENAME> model HM-CC-TC
attr <DEVICENAME> room <ROOM>
attr <DEVICENAME> serialNr <SERIAL>
attr <DEVICENAME> subType thermostat
attr <DEVICENAME> webCmd getConfig:clear msgEvents:burstXmit
attr <DEVICENAME> event-on-change-reading .*

define FileLog_<DEVICENAME> FileLog ./log/<DEVICENAME>-%Y.log <DEVICENAME>
attr FileLog_<DEVICENAME> logtype text
attr FileLog_<DEVICENAME> room <ROOM>

#------ Channels of <DEVICENAME> in <ROOM>

define <DEVICENAME>_Weather CUL_HM <HMID>01
attr <DEVICENAME>_Weather model HM-CC-TC
attr <DEVICENAME>_Weather room <ROOM>
attr <DEVICENAME>_Weather peerIDs <PEERWEATHER>

define <DEVICENAME>_Climate CUL_HM <HMID>02
attr <DEVICENAME>_Climate model HM-CC-TC
attr <DEVICENAME>_Climate room <ROOM>
attr <DEVICENAME>_Climate webCmd desired-temp:controlMode
attr <DEVICENAME>_Climate peerIDs <PEERCLIMATE>

define FileLog_<DEVICENAME>_Climate FileLog ./log/<DEVICENAME>-%Y.log <DEVICENAME>_Climate
attr FileLog_<DEVICENAME>_Climate logtype text
attr FileLog_<DEVICENAME>_Climate room <ROOM>

define <DEVICENAME>_WindowRec CUL_HM <HMID>03
attr <DEVICENAME>_WindowRec model HM-CC-TC
attr <DEVICENAME>_WindowRec peerIDs <PEERWINDOW>
attr <DEVICENAME>_WindowRec stateFormat last:trigLast

#------ Create a custom temperature view for <DEVICENAME>

define weblink_<DEVICENAME> SVG FileLog_<DEVICENAME>:HM-CC-TC:CURRENT
attr weblink_<DEVICENAME> alias <DEVICENAME>
attr weblink_<DEVICENAME> label "<DEVICENAME> min: $data{min1} °C, max: $data{max1} °C, Last: $data{currval1} °C"
attr weblink_<DEVICENAME> captionPos left
attr weblink_<DEVICENAME> room <ROOM>

#------ Define a dummy that holds the desired temperature of the <DEVICENAME>

define <DEVICENAME>_DesiredTemp dummy
attr <DEVICENAME>_DesiredTemp room <ROOM>

#------ Define additional notifiers to avoid NACK and repsonse erros

define <DEVICENAME>_Update notify <DEVICENAME> {my $d = ReadingsVal("<DEVICENAME>","desired-temp","10");; fhem("set <DEVICENAME>_DesiredTemp $d");; }

define <DEVICENAME>_WD watchdog <DEVICENAME>:set_desired-temp.* 00:02:30 <DEVICENAME>_Climate:CommandAccepted:.yes { \
   Log 1, ">>>>>>>>> <DEVICENAME>_WD desired temp - missing response.";;\
   fhem("set <DEVICENAME> desired-temp".Value("<DEVICENAME>_DesiredTemp"));; }

define <DEVICENAME>_ErrNotif notify <DEVICENAME>:(MISSING.ACK.*|.*NACK.*) {\
   Log 1, ">>>>>>>>> <DEVICENAME>_ErrNotif desired temp - missing ack/nack.\n";;\
   fhem("set <DEVICENAME> desired-temp".Value("<DEVICENAME>_DesiredTemp"));; }

#--------------- End of <DEVICENAME> --------------

frank

paire grundsätzlich alle devices mit fhem, also auch die vd.
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

smoneck

Zitat von: frank am 30 Oktober 2017, 14:35:32
paire grundsätzlich alle devices mit fhem, also auch die vd.

Danke fuer deine Antwort! Das heisst gar nicht mit dem HM-CC-TC? Oder vor oder nach dem TC?

viegener

Sorry klassischer Fehler:
peering und pairing ist nicht das gleiche. Siehe Einsteigerdoku zu HM:

Pairing mit FHEM sollte immer erfolgen - das Anlernen an der Zentrale

Peering erfolgt direkt zwischen Devices, damit Temperatureinstellungen auch am Ventil an der Heizung übernommen werden.

Meine Regel
- Pairing immer und (normalerweise) vor dem peering - durchführen überprüfen und dann erst weiter
- Peering danach, damit es sich leicht in FHEM überprüfen lässt - also durchführen überprüfen und bei Bedarf wiederholen

Ein klassisches Problem beim Peeren ist, dass nur ein Device akzeptiert, das kann man durch entsprechende Befehle "nachpeeren" oder eben zurücknehmen

Alles sehr gut im wiki erklärt - wenn da sachen fehlen oder unklar sind - wiki account beantragen und hinzufügen



Kein Support über PM - Anfragen gerne im Forum - Damit auch andere profitieren und helfen können

viegener

Achso - wichtige Zusatzinfo: Sowohl peering also auch pairing wird im HM-Gerät gespeichert, deshalb auch die Hinweise zum Sichern der Konfiguration anschauen, das kann hilfreich sein, um nach einem Werksreset o.ä. wieder schnell alles am Laufen zu haben
Kein Support über PM - Anfragen gerne im Forum - Damit auch andere profitieren und helfen können

smoneck

Ah, okay. Dachte Peering geschieht auf Seiten FHEMs ...

Aber meine Vorgehensweise entspricht genau dem hier im ersten Teil beschriebenen Verfahren.

Ist es moeglich, dass ich die VDs noch nachtraeglich paire? Oder muesste ich alles komplett zurueck setzten und dann neu anfangen?

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

smoneck

Okay, super! Dann fange ich naechste Woche an die VDs nachtraeglich zu pairen und schaue mal, ob die Warnungen verschwinden.
Vielen lieben Dank!

smoneck

Ich habe mich jetzt noch einmal dran versucht aber keine Aenderung bisland:


  • Wenn ich den VD erst an FHEM versuche anzulernen, gibt er danach beim peering mit der TC einen Fehler F5. Und ich muss ihn langwierig zuruecksetzen.
  • Wenn ich den VD erst mit der TC peere und dann die TC mit FHEM paire(?) und dann noch einmal versuche den VD mit FHEM zu peeren(?), bleibt alles beim alten: Die TC ist von FHEM steuerbar und damit indirekt die VDs als Ganzes aber nicht einzeln und FHEM wirft peer list incomplete.

Damit bin ich glaube ich alle Permutationen durch und wieder beim Ausgangspunkt. :|

frank

ZitatWenn ich den VD erst an FHEM versuche anzulernen, gibt er danach beim peering mit der TC einen Fehler F5. Und ich muss ihn langwierig zuruecksetzen.
logisch, denn geräte, die bereits mit einer zentrale gepairt sind, lassen sich nicht mehr "direkt" peeren. nur noch über die zentrale.

ZitatWenn ich den VD erst mit der TC peere und dann die TC mit FHEM paire(?) und dann noch einmal versuche den VD mit FHEM zu peeren(?), bleibt alles beim alten: Die TC ist von FHEM steuerbar und damit indirekt die VDs als Ganzes aber nicht einzeln und FHEM wirft peer list incomplete.
nicht peeren sondern pairen.
poste ein list vom vd.
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

smoneck

Zitat von: frank am 06 November 2017, 16:05:40
nicht peeren sondern pairen.
:-X

Zitat von: frank am 06 November 2017, 16:05:40
poste ein list vom vd.

Klar, einfach irgendeinen aus der Mitte gegriffen:

Internals:
   DEF        232C04
   HMLAN00_MSGCNT 8571
   HMLAN00_RAWMSG E232C04,0000,B3831709,FF,FFB1,9F8202232C04230E6B010166002D
   HMLAN00_RSSI -79
   HMLAN00_TIME 2017-11-13 17:29:57
   IODev      HMLAN00
   LASTInputDev HMLAN00
   MSGCNT     8571
   NAME       Thermostat_A2
   NOTIFYDEV  global
   NR         1115
   NTFY_ORDER 50-Thermostat_A2
   STATE      51
   TYPE       CUL_HM
   lastMsg    No:9F - t:02 s:232C04 d:230E6B 010166002D
   protCmdDel 4
   protLastRcv 2017-11-13 17:29:57
   protResnd  3 last_at:2017-09-28 14:39:02
   protResndFail 1 last_at:2017-09-28 14:46:37
   protSnd    4 last_at:2017-09-28 14:46:35
   protState  CMDs_done_Errors:1
   rssi_Thermostat avg:-47.41 min:-62 max:-40 cnt:8571 lst:-45
   rssi_at_HMLAN00 max:-69 avg:-79.42 min:-105 lst:-79 cnt:8571
   Readings:
     2017-11-04 18:05:18   Activity        alive
     2017-11-13 17:29:57   CommandAccepted yes
     2016-08-24 08:09:34   D-firmware      2.0
     2016-08-24 08:09:34   D-serialNr      KEQ0634188
     2017-11-13 17:29:57   ValveDesired    51
     2017-11-13 17:29:57   ValvePosition   51
     2017-11-13 17:29:57   battery         ok
     2017-11-13 17:29:57   motor           stop
     2017-11-13 17:29:57   motorErr        ok
     2017-11-13 17:29:57   operState       onTarget
     2017-11-13 10:09:44   operStateErrCnt 425
     2017-11-13 17:29:57   recentStateType ack
     2017-11-13 17:29:57   state           51
   Helper:
     HM_CMDNR   159
     getCfgListNo
     mId        003A
     oldDes     51
     rxType     12
     supp_Pair_Rep 0
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +232C04,00,00,00
       nextSend   1510590597.62708
       prefIO
       rxt        2
       vccu
       p:
         232C04
         00
         00
         00
     Mrssi:
       mNo        9F
       Io:
         HMLAN00    -77
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Rssi:
       Thermostat:
         avg        -47.412320616031
         cnt        8571
         lst        -45
         max        -40
         min        -62
       At_hmlan00:
         avg        -79.4270213510675
         cnt        8571
         lst        -79
         max        -69
         min        -105
     Shadowreg:
     Tmpl:
Attributes:
   IODev      HMLAN00
   actCycle   000:20
   actStatus  alive
   autoReadReg 4_reqStatus
   event-on-change-reading .*
   expert     2_raw
   firmware   2.0
   model      HM-CC-VD
   room       Room
   serialNr   KEQ0634188
   subType    thermostat
   webCmd     getConfig:clear msgEvents:burstXmit


viegener

Der Device von oben Thermostat_A2 zeigt kein pairing mit FHEM als Zentrale, das muss auf jeden Fall noch gemacht werden.

Das peering wäre in den channnels sichtbar insofern wäre nach dem pairing und dem erfolgreichen getConfig ein list der channels in denen ein peering existieren sollte.

Und ich gehe immer noch davon aus, dass die GetConfig-Meldungen wirklich auf ein Problem hindeuten (im besten fall, dass die Konfigurationsdaten in FHEM nicht aktuell ist)

Kein Support über PM - Anfragen gerne im Forum - Damit auch andere profitieren und helfen können