mal wieder ein peering - Problem :(

[M_I_B]

Moin...

... wollte vorhin einen Wandthermostaten (HM-TC-IT-WM-W-EU) mit einem Hutschinen-Aktor (HM-LC-SW4-DR) peeren, also Kanal 7 des Thermostaten mit Aktor 4

Bei meinem Thermostaten sind die Kanäle durchnummeriert, so das der interne Kanal 7 (SwitchTr) anzusprechen ist als HM5TH2_5. Ähnliches gilt für den Aktor, d bei dem der 4. Kanal anzusprechen ist als HM4SW2_4.

Somit habe ich mich angelehnt an das HowTo https://wiki.fhem.de/wiki/HM-TC-IT-WM-W-EU_Funk-Wandthermostat_AP an dem Folgenden versucht:

set HM5TH2_5 peerChan 0 HM4SW2_4 single set

... und dann ...

set HM4SW2_4 regSet shCtOn ltLo HM5TH2_5


Beides ist ohne jegliche Fehlermeldung in der GUI wie auch im LOG vonstatten gegangen. Und offensichtlich funktioniert das alles auch. Der Brenner wird korrekt an- und ausgeschaltet (Propangas- Bauheizer 20kw). Dennoch wird im Kanal 7 des Wandthermostaten, also bei mir HM5TH2_5, immer noch "unpeered" angezeigt...

Funktioniert nicht wirklich. Der Brenner wird zwar eingeschaltet, aber nicht wieder abgeschaltet (eingestellt ist 6,5°C SOLL, gerade lief der Brenner bei 7,9°C IST immer noch)


Menno... Was läuft denn da bei mir schon wieder falsch?!?

Nachlieferung der Listings...

Aktor:

Code Auswählen Erweitern

Internals:
   CFGFN      /opt/fhem/_HW/HM.aktoren.cfg
   DEF        3A5CE404
   NAME       HM4SW2_4
   NOTIFYDEV  global
   NR         674
   STATE      off
   TYPE       CUL_HM
   chanNo     04
   device     HM4SW2
   READINGS:
     2018-02-02 20:13:54   .R-HM5TH2_5-lgCtDlyOff geLo
     2018-02-02 20:13:54   .R-HM5TH2_5-lgCtDlyOn geLo
     2018-02-02 20:13:54   .R-HM5TH2_5-lgCtOff geLo
     2018-02-02 20:13:54   .R-HM5TH2_5-lgCtOn geLo
     2018-02-02 20:13:54   .R-HM5TH2_5-lgCtValHi 100
     2018-02-02 20:13:54   .R-HM5TH2_5-lgCtValLo 50
     2018-02-02 20:13:54   .R-HM5TH2_5-lgMultiExec on
     2018-02-02 20:13:54   .R-HM5TH2_5-lgOffDly 0 s
     2018-02-02 20:13:54   .R-HM5TH2_5-lgOffTime unused
     2018-02-02 20:13:54   .R-HM5TH2_5-lgOffTimeMode absolut
     2018-02-02 20:13:54   .R-HM5TH2_5-lgOnDly 0 s
     2018-02-02 20:13:54   .R-HM5TH2_5-lgOnTime unused
     2018-02-02 20:13:54   .R-HM5TH2_5-lgOnTimeMode absolut
     2018-02-02 20:13:54   .R-HM5TH2_5-lgSwJtDlyOff off
     2018-02-02 20:13:54   .R-HM5TH2_5-lgSwJtDlyOn on
     2018-02-02 20:13:54   .R-HM5TH2_5-lgSwJtOff dlyOn
     2018-02-02 20:13:54   .R-HM5TH2_5-lgSwJtOn dlyOff
     2018-02-02 20:13:54   .R-HM5TH2_5-shCtDlyOff geLo
     2018-02-02 20:13:54   .R-HM5TH2_5-shCtDlyOn geLo
     2018-02-02 20:14:07   .R-HM5TH2_5-shCtOff set_geLo
     2018-02-02 20:14:07   .R-HM5TH2_5-shCtOn set_ltLo
     2018-02-02 20:13:54   .R-HM5TH2_5-shCtValHi 100
     2018-02-02 20:13:54   .R-HM5TH2_5-shCtValLo 50
     2018-02-02 20:13:54   .R-HM5TH2_5-shMultiExec off
     2018-02-02 20:13:54   .R-HM5TH2_5-shOffDly 0 s
     2018-02-02 20:13:54   .R-HM5TH2_5-shOffTime unused
     2018-02-02 20:13:54   .R-HM5TH2_5-shOffTimeMode absolut
     2018-02-02 20:13:54   .R-HM5TH2_5-shOnDly 0 s
     2018-02-02 20:13:54   .R-HM5TH2_5-shOnTime unused
     2018-02-02 20:13:54   .R-HM5TH2_5-shOnTimeMode absolut
     2018-02-02 20:13:54   .R-HM5TH2_5-shSwJtDlyOff off
     2018-02-02 20:13:54   .R-HM5TH2_5-shSwJtDlyOn on
     2018-02-02 20:13:54   .R-HM5TH2_5-shSwJtOff dlyOn
     2018-02-02 20:13:54   .R-HM5TH2_5-shSwJtOn dlyOff
     2018-01-07 18:31:27   .R-statusInfoMinDly 2 s
     2018-01-07 18:31:27   .R-statusInfoRandom 1 s
     2018-01-07 18:31:27   .R-transmitTryMax 6
     2018-02-02 20:13:53   .peerListRDate  2018-02-02 20:13:53
     2018-02-02 20:49:14   CommandAccepted yes
     2018-02-02 20:13:54   R-HM5TH2_5-lgActionType jmpToTarget
     2018-02-02 20:13:54   R-HM5TH2_5-shActionType jmpToTarget
     2018-01-07 18:31:27   R-powerUpAction off
     2018-01-07 18:31:27   R-sign          off
     2018-02-02 20:13:53   RegL_01.        08:00  30:06 57:24 56:00 00:00
     2018-02-02 20:13:54   RegL_03.HM5TH2_5 02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:01 0B:14 0C:63 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:21 8B:14 8C:63
     2018-02-02 20:49:14   deviceMsg       off (to VCCU)
     2018-02-02 20:49:14   level           0
     2018-02-02 20:49:14   pct             0
     2018-02-02 20:49:14   recentStateType ack
     2018-02-02 20:49:14   state           off
     2018-02-02 20:49:14   timedOn         off
   helper:
     regLst     ,1,3p
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     role:
       chn        1
     tmpl:
Attributes:
   alias      Garage Gasbrenner
   devStateIcon off|set_on:scene_stove@gray:on on|set_off:scene_stove@lime:off
   group      _90 HW - HM.SW
   model      HM-LC-SW4-DR
   peerIDs    00000000,
   room       _90 HW - HM.SW,121 - Garage
   webCmd     :

Thermostat Schalterkanal 7:

Code Auswählen Erweitern

Internals:
   CFGFN      /opt/fhem/_HW/HM.thermostate.cfg
   DEF        4E71B807
   NAME       HM5TH2_5
   NOTIFYDEV  global
   NR         946
   STATE      unpeered
   TYPE       CUL_HM
   chanNo     07
   device     HM5TH2
   READINGS:
     2018-02-02 21:04:22   level           0
     2018-02-02 20:53:30   state           unpeered
     2018-02-02 21:04:22   trigger_cnt     22
   helper:
     regLst     ,1,7p
     expert:
       def        1
       det        1
       raw        0
       tpl        0
     role:
       chn        1
     tmpl:
Attributes:
   alias      Schalter
   group      _90 HW - HM.TS
   model      HM-TC-IT-WM-W-EU
   peerIDs    00000000,
   room       _90 HW - HM.TS,121 - Garage

[Pfriemler]

Seltsam. Sieht auch für mich erst mal alles richtig aus, inkl. shCtOn auf ltLo.

getConfig auf den Thermostaten oder wenigstens den Schaltkanal schon gemacht? Eventuell ist das Peering dort eingetragen, aber FHEM weiß noch nichts davon. Wenn es auch dann nicht kommt, nochmal peeren.

ggf. auch noch ein getConfig auf den Schaltkanal und dann nochmal die Registerprogrammierung prüfen: Ohne Fehlermeldung heißt nur, es wurde erfolgreich abgeschickt. Derzeit steht noch "set_" vor dem Reading, "das muss noch weg" wie wir so schön sagen.

Schaue bitte, ob im 2. Kanal (_climate) das Register "heatCool" auf "heating" steht und nicht aus früheren Versuchen auf "cooling".

Jm2c.

[martinp876]

warum nicht die vorhandenen Mittel von FHEM / CUL_HM nutzen um sein System zu bedienen und zu kontrollieren?

Mein Vorschlag:
1) das System ist aufgesetzt

Code Auswählen Erweitern

define hm HMinfo
attr hm autoArchive 1
attr hm configFilename regConfig.cfg
attr hm autoLoadArchive 1_load

define ht HMtemplate

attr TYPE=CUL_HM:FILTER=DEF=......:FILTER=subType!=virtual autoReadReg             5_readMissing


2)peeren

Code Auswählen Erweitern

set HM5TH2_5 peerChan 0 HM4SW2_4 single set
set HM4SW2_4 statusRequest # ein Bug: das peering wird nicht übertragen sondern hängt in der Queue... muss ich beheben

3) ein template kann mit ht definiert werden. Hier mein Vorschlag

Code Auswählen Erweitern

set hm templateDef RtSwitchCtrl onTime "switch controlled by TC" shOnTime:p0 shActionType:jmpToTarget shCtDlyOn:ltLo shCtValHi:100 shOffDly:0 shOffTime:unused shOnDly:0 lgActionType:off shSwJtOn:dlyOff shCtValLo:50 shCtOff:geLo shOffTimeMode:absolut shCtOn:ltLo shSwJtOff:dlyOn shCtDlyOff:geLo shOnTimeMode:absolut shSwJtDlyOn:dlyOff shSwJtDlyOff:dlyOn


4) template anwenden. Ich habe die maximale onTime als Parameter im Template eingebaut - also muss es eingegeben werden.
offne ht im browser

Code Auswählen Erweitern

set ht select RtSwitchCtrl
attr ht tpl_entity HM4SW2_4
attr ht tpl_ePeer HM5TH2_5
attr ht tpl_param_onTime 1200
set ht apply
save


5) kontrolle

Code Auswählen Erweitern

get hm checkConfig
get hm protoEvents


6) ggf nachbessern, templates noch einmal übertragen lassen - für alle devices welche ein Problem haben

Code Auswählen Erweitern

set hm templateExe

Damit sparst du dir ein Prüfen, ob alles übertragen ist, ob es ein ack gegeben hat, ob noch ein set_ drin steht.

[M_I_B]

Moin Martin,

Du überforderst einen alten Mann gerade maßlos Ich verstehe nur Bahnhof

Inzwischen hat es aber geklappt. Ich hatte zwischenzeitlich Sensor so wie Aktor auf Werkseinstellungen gesetzt, neu in FHEM bekannt gemacht und dann noch mal versucht (nebst ständigem getConfig u.ä.)... Kein Erfolg resp. gleiches Problem wie vorher: Peering wurde nicht dargestellt; eingeschaltet wurde trotzdem, aber nie aus (bei einem Gasheizer mit Flaschengas eher tödlich).
Ich habe dann einen Dummy gebaut, welcher alle 5 Minuten den Kommandosatz übertragen hat (1. peer, getConfig, 2. peer, getConfig, 1. peer, ...) und habe ne 3/4 Stunde u.a. mit einem uralten Bimetall- Wandthermostat einen Zwischenstecker gebaut als Plan B. Doch oh Wunder... Dann hat es hingehauen! Waren zwar extrem viele "commands pending" bei beiden Geräten, aber die habe ich dann stumpf entsorgt. Manchmal hilft halt auch bei HM eine Gehirnwäsche
Ok, so soll es natürlich nicht sein, aber ich musste gestern Nacht zwingend eine Lösung fnden.

Zu Deinem Vorgehen Martin... Ganz ehrlich? Verstehe ich noch nicht mal im Ansatz, was Du da machst. Ok, was ein Template ist habe ich inzwischen begriffen und nutze sowas ja, um z.B. immer wiederkehrende DOIF- Konstrukte mit einem Satz zu erschlagen. Und wenn ich das richtig erahne, nutzt Du ein Template um ein Peering zwischen zwei geräten herzustellen und gleichzeitig zu kontrollieren, ob das alles korrekt gelaufen ist?

[Pfriemler]

HMInfo ist eine für die Wartung relativ unverzichtbare Kontrollkomponente, und Templates sind dazu gedacht, ganze Registersätze nach manuell erfolgtem Peering einzustellen. Da sich die Einstellungen hier auf das Setzen von shCtOn auf ltLo beschränken, ist der Nutzen eines Templates zunächst nicht ersichtlich, aber FHEM merkt sich die Wunschprogrammierung und kontrolliert sie dann auch selbstständig. Allerdings muss man dann auch auf die Meldungen von HMInfo achten. Abgesehen davon schadet es nichts zu wissen, wie die Zusammenhänge dahinter funktioneren.

Dass man einen statusrequest immer nachsetzen sollte wegen eines hängenden Bugs, ist mir auch neu.

Und ja: Manchmal hilft es, den Berg an Kommandos zu löschen (clear msgInfo ist das Mittel) und von vorn anzufangen. Da ist es ganz und gar kontraproduktiv, immer neue Befehle zu generieren, bevor die alten abgearbeitet sind. Also peeren und getConfigs oder statusRequests bis das Peering durch ist. Dann erst die Register setzen und wieder abwarten. Thermostate reagieren auch nicht unbedingt sofort auf die Anforderungen, etwas Geduld schadet nicht. Gerade die Heizkörperthermostate brauchen gern mal eine Viertelstunde bis alles durch ist.

Martins template macht quasi eine Gehirnwäsche am Aktor, da wird (meist unnötigerweise) doch vieles auf ohnehin vorhandene defaults gesetzt. Allerdings ist die Kontrolle dann dafür umso gründlicher.

[martinp876]

Zuerst einmal solltest du hminfo einrichten und die Optionen testen. Eigentlich setze ich voraus, dass man hminfo sowieso betreibt. Ich betrachte die Funktionen wie configcheck und protoevents als Basics. Schaue es dir einmal an.

Ebenso sehe ich es mit dem sichern der Register in einem File. Macht hminfo mit dem save. Die Attribute musst du setzen wie angegeben.
AutoReadReg empfehle ich ( dringend) für alle devices. Auch hier einfach das Kommando zum setzen der Attribute ausführen. Geht 1:1.

Nun erst kommt das Template. Pfriemler hat fast Recht. Wenn du 2 Register setzt musst du prüfen, dass es geklappt hat, du selbst manuell. Geht etwas schief ( sollte nicht, ist nicht ausgeschlossen) liegt es an dir, es zu merken. Wenn du nur 2 devices hast, kannst du es mit liebe prüfen.

Nutzt du Templates ( ein Template ist eine Blaupause, für uns ältere. Allerdings sprichst du evtl von anderen Templates) dann prüft hminfo alles. Grundsätzlich ist hminfo configcheck das eine Kommando, das die komplette config auf Einhaltung prüft. Das 2. unverzichtbare ist protoEvents.

[M_I_B]

... Deinen ersten Satz kann ich abhaken. HMinfo ist seit Anfang an am Start, den Rest nutze ich seit einiger Zeit, nachdem ich es gesagt bekam und erkannt habe, für was das gut ist

Mit der Templatenummer werde ich mich mal intensiver beschäftigen. Scheint ziemlich schlau zu sein. Aber sowas dauert bei mir immer ein bisschen...

Aber mal was anderes in dem Zusammenhang...
Bin mit der Nummer gerade auf ein Problem gestoßen ablauftechnischer Art:
So ein Gasbrenner hat manchmal die dumme Angewohnheit, nicht zünden zu wollen. Ich habe den zwar schon umgebaut (stärkerer Zündtrafo, kleine Zündkammer, ...), aber dennoch schlägt gefühlt jeder 100ste Start fehl. Passieren tut da nix, da der Brenner dann auf Störung schaltet, wenn nicht innerhalb von 5 Sekunden nach Gaszufuhr eine saubere Verbrennung da ist. Aber genau da liegt auch mein Problem begründet...
Wenn der Thermostat dem Aktor "Brenner an" mitteilt und der Brenner dann auf Störung geht, passiert halt.... nix. Die Bude kühlt dann halt vollkommen aus, bis es jemand merkt.

Man müsste jetzt also irgend was konstruieren, das der Brenner im Falle einer Störung abgeschaltet und nach z.B. einer Minute neu gestartet wird (Netzspannung wegnehmen = Reset der Störung). Und dieses Konstrukt müsste noch in so weit eingeschränkt werden, das z.B. maximal 3 Startversuche gemacht werden; kann ja auch sein, das die Gasflasche leer ist oder ein anderer Fehler vorliegt...

Hat da jemand einen Denkanstoß zu?

[martinp876]

Nun, woran kannst du erkennen, dass der Brenner brennt? Mir fällt temperatur ein. Wenn der Brenner brennen soll sollte die temp steigen, oder einen minimalwert haben. Also ein tempfühler und eine steuerung in der zentrale.

[M_I_B]

... au backe, wie doof kann man sein?! Natürlich, hast vollkommen recht Ist ja schon alles da, was man benötigt ...
Manchmal sehe ich den Wald vor lauter Bäumen nicht ...

Danke für den Schubser...

[M_I_B]

... tja ... Geht so nicht wirklich, denke ich ...

Ich bin gerade dabei, ein DOIF- Konstrukt zu zimmern, welches die Überwachung auf Störfälle übernimmt. Dabei bin ich auf ein schnödes Problem gestoßen: Ein beliebiger Kanal eines Hutschinenaktors lässt sich nicht mit "disable" abschalten. Das ist aber zwingend notwendig, wenn z.B. drei Startversuche erfolglos waren.

Dazu finde ich leider keine Lösung, so lange Thermostat und Kanal direkt gepeert sind...

Ne andere Idee?

[martinp876]

Den thermostat mit schalter direkt peeren geht nicht. Der sendet keine Trigger, nur Temperatur.
Ich wuerde dies über die Zentrale lösen.

[M_I_B]

... hu? HM-TC-IT-WM-W-EU mit HM-LC-SW4-DR peeren geht doch fast problemlos und läuft ja nun seit zwei Tagen; oder reden wir gerade aneinander vorbei?
Mir fehlt eine Lösung, die Beiden im GAU- Fall an einer Interaktion zu hindern, also entweder dem Thermostaten das Senden eines ON- Befehls zu verbieten oder aber dem entsprechenden Aktor- Kanal die Annahme resp. Ausführung eines ON- Befehls zu verbieten.

Die einzige Lösung, die mir gerade im Kopf rumeiert ist halt, wie Du schon sagst, das Peering aufzuheben und alles über die Zentrale laufen zu lassen. Das hat allerdings im Moment den Haken, das Thermostat wie auch Aktor im Grenzbereich der Reichweite liegen (Garage hat noch kein LAN; kommt im Frühjahr) und somit schon mal eine Minute oder so vergeht, bis was passiert... Eine Minute bei 20kw ist schon was....

[martinp876]

Ok, geht. Wenn du ihn korrekt positionieren kannst. Ich denke, das kannst nur du beurteilen.

[Pfriemler]

... Ein beliebiger Kanal eines Hutschinenaktors lässt sich nicht mit "disable" abschalten. Das ist aber zwingend notwendig, wenn z.B. drei Startversuche erfolglos waren.

"set <channel> inhibit on" blockiert den Kanal für alle Peers, so dass Direktverknüpfungen nicht mehr ausgeführt werden, "off" deaktiviert die Sperre wieder. Damit funktioniert aber auch die lokale Taste nicht mehr.
Steuerung über FHEM (set <channel> on/off) ist aber weiterhin möglich.

[M_I_B]

... Ha! Das wollte ich wissen! Super! ... Vielen Dank!
Das versuche ich heute Abend gleich mal umzusetzen. Direkte Kontrolle via Taste am Aktor ist uninteressant, kann ich also super mit leben. Es geht wie gesagt ausschließlich darum, ein Wiedereinschalten durch den direkt gepeerten Thermostaten im Störfall zu verhindern.
Und das ganze ist ja auch nur temporär, bis die Temperaturen wieder stabil 24/7 über 6°C liegen... In dem Zusammenhang ist mir gestern noch eingefallen, das man dem Brenner fest verbaut ja vielleicht mal einen WeMOS spendieren könnte; wäre ja auch nicht so doof und flexibler, falls man den Brenner mal außerhalb der FHEM- Enklave nutzen möchte... Aber das muss warten bis zum Frühjahr... bis Ende des Jahres ist hoffentlich das Projekt "Garagenumbau" nebst Isolierung abgeschlossen. Dann brauche ich da nicht mehr solche Energiemengen, sondern dann sollten getaktete 1kW ausreichend sein, die Hütte auf Temperatur zu halten...