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:
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:
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
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.
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
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
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
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
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
get hm checkConfig
get hm protoEvents
6) ggf nachbessern, templates noch einmal übertragen lassen - für alle devices welche ein Problem haben
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.
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 ;D
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?
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.
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.
... 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?
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.
... 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...
... 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?
Den thermostat mit schalter direkt peeren geht nicht. Der sendet keine Trigger, nur Temperatur.
Ich wuerde dies über die Zentrale lösen.
... 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....
Ok, geht. Wenn du ihn korrekt positionieren kannst. Ich denke, das kannst nur du beurteilen.
Zitat von: M_I_B am 05 Februar 2018, 20:08:29
... 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.
... 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...
... kann man irgendwie erkennen / auslesen ob die "Hemmung" aktiv (ON) ist oder nicht (OFF)?
... Augen auf... Schon gefunden ;)
EDIT sagt:
Klappt (vermutlich nur bei mir) mal wieder nicht. Ich kann den Befehl zwar absetzen, aber der Aktor-Kanal steht jetzt seit Stunden auf "inhibit - set_on". Da hilft auch kein getConfig o.ä., was ich aus der Ferne machen kann...
Diese Lösung scheidet also aus, da nicht kalkulierbar ist, wann sich der Aktor denn bequemen mag, den Befehl anzunehmen...
Ich werde also notgedrungen jetzt auf die reine Steuerung über die Zentrale ausweichen oder Plan-B umsetzen (Bimetall- Thermostat, Stromgesteuerter Quecksilber-Zeitschalter / Museal, aber zuverlässig seit mindestens 60 Jahren...)
Zitatder Aktor-Kanal steht jetzt seit Stunden auf "inhibit - set_on".
getconfig ist sinnlos. mehr kommt hier auch nicht, da fhem inhibit leider immer noch nicht auslesen kann.
wenn der aktor das kommando gehört hat, sollte es funktionieren, also probieren.
ansonsten könntest du das register shActionType=off setzen, damit die trigger ignoriert werden.
... ne, funktioniert leider nicht. Der Aktor reagiert weiterhin auf die ON- Befehle des Thermostaten. Die andere Version probiere ich auch noch mal heute Abend ... Danke für den Hinweis!
Tja, soweit Theorie und Praxis. inhibit wird eigentlich gern genutzt. Denkbar, dass es der Sw4-DR wegen eines Konfigurationsfehlers seitens eQ3 oder FHEM real doch nicht untersützt.
Meinen Rolladenaktor für die Terrassenmarkise lege ich so jedenfalls sehr erfolgreich auch lokal lahm und damit sicher vor unnötigen winterlichen Fehlbedienungen.
Der von frank vorgeschlagene Weg sollte aber in jedem Fall funktionieren.
edit: Dieses Register ist allerdings peer-bezogen, Du musst also den Thermostaten als Parameter angeben. inhibit wirkt - wenn - dann global.
... tja, schön wär's gewesen ...
shActionType ist auch nicht wirklich zielführend; dauert zu lange, bis der Aktor das gefressen hat...
Ich habe also das Peering wieder komplett entfernt und versuche es noch mal über die Zentrale mit ein bisschen Antenne rücken...
In dem Zusammenhang erlaube ich mir mal eine Frage:
### BRENNER ###
define set_brenner DOIF ([HM4SW2_4] eq "off" and [HM5TH2:measured-temp] < [HM5TH2:desired-temp]-1 and [gas_count] =< 3)(set HM4SW2_4 on,{fhem 'set gas_time '.strftime('%M', localtime)},set gas_temp [HM5TH2:measured-temp])
define set_stoerung DOIF ([HM4SW2_4] eq "on" and [gas_time]+1 == {fhem strftime('%M', localtime)} and [HM5TH2:measured-temp] > [gas_temp])(set gas_count 0) \
DOELSEIF ([HM4SW2_4] eq "on" and [gas_time]+1 == {fhem strftime('%M', localtime)} and [HM5TH2:measured-temp] =< [gas_temp])(set gas_count [gas_count]+1,set HM4SW2_4 off)
attr set_stoerung do always
Das habe ich gerade mal so zwischen Tür und Angel hingeschi**** und ist natürlich noch nicht getestet. Ich denke auch, das ich da mit der Zeitsache gegen die Wand laufen werde. Das ist bestimmt vom Syntax her falsch. Darauf zielt auch meine Frage ab...
Ich speichere beim Start des Brenners die aktuelle Uhrzeit (nur die Minuten) in einem Dummy (kann DOIF das inzwischen nativ? Habe nix finden können...). Nun möchte ich nach einer Zeit X (hier eine Minute) nachsehen, ob die IST-Temperatur im Raum gestiegen ist. Also addiere ich zum Dummy 1 dazu und vergleiche es mit der aktuellen Uhrzeit-Minuten. ABer so wie ich das gemacht habe, geht das sicherlich nicht...
HowTo?
BTW: Einen Dummy de/incrementieren via ++ oder -- oder so geht auch nicht, oder?
... also so langsam geht mir das Zeugs mächtig auf den Senkel >:( >:( >:(
Erste Problem: Das Peering des Wandthermostat lässt sich ums Verrecken nicht mehr löschen. "set HM5TH2_5 peerChan 0 HM4SW2_4 unset" erzeugt manchmal ein "unpaired" in state und in STATE, aber wenn ich nach einigen Minuten noch mal schaue, ist das Peering wieder da. Das kann ich beliebig wiederholen, mit und ohne "getConfig" zwischendurch und auch ein Firmware-Reset des Thermostaten und anschließendes neu Einbinden in FHEM hilft nicht weiter :o >:( >:(
Zweites Problem: Irgendwie bekomme ich es nicht mehr hin, im Ausführungsteil eines DOIF zu rechnen. "(set gas_count ({[gas_count]+1}))", "(set gas_count {[gas_count]+1})" und ebenso "(set gas_count [gas_count]+1)" funktionier nicht. Ich will nichts weiter, als den Wert im Dummy um 1 erhöhen / incrementieren; kann doch nicht so schwer sein... Himmel Ar*** und Zwirn ...
Also.
Nach einem Reset des Thermostaten und einem Neuanlernen in FHEM MUSS das Peering im Thermostaten (nicht im Aktor) weg sein. Anderenfalls wurde der Thermostat nicht richtig zurückgesetzt.
Dann möchte ich noch auf zwei Spezies von "peerChan" hinweisen:
1. Du verbindest oder trennst einen Kanal. Default gibt es aber zwei Kanäle.
"set HM5TH2_5 peerChan 0 HM4SW2_4
single unset" ist dann richtig. Übrigens gibt es Schiffbruch, wenn Du auch das Peering ohne single machst. Das zu erklären führt hier aber zu weit.
2. Ist der Thermostat einmal "leer", zeigt also kein Peering, kannst Du es aus dem Actor auch mit
""set HM5TH2_5 peerChan 0 HM4SW2_4 single unset
actor"
allda entfernen, ohne dass dabei der Thermostat nochmals "angefasst" wird. Das Gerät muss aber definiert sein, sonst gibt es einen Fehler. Gibt es das nicht mehr, hilft dann peerBulk weiter, aber das ist wieder eine andere Geschichte.
Im DOIF-Help ("Device specific help" am Fuß der Definition) finde ich
ZitatBerechnungen können in geschweiften Klammern erfolgen. Aus Kompatibilitätsgründen, muss die Berechnung unmittelbar mit einer runden Klammer beginnen. Innerhalb der Perlberechnung können Readings, Status oder Internals wie gewohnt in eckigen Klammern angegeben werden.
"(set gas_count ({[gas_count]+1}))" wäre demnach richtig. Eigentlich identisch wäre "(set gas_count ({[gas_count
:state]+1}))
Den Rest durchblicke ich jetzt nicht. Ggf. frag nochmal im DOIF-Unterforum zu "Automatisierungen" nach.
Was passiert, wenn nach den Kommandos nix passiert.?
Fehlerhafte messages? Pending? Abbrüche?
... das Peering - Problem habe ich nun anders gelöst, in dem ich den Code händisch aus der CFG gekickt habe... Hintergrund scheint zu sein, das ich einer der "verhassten" Direkeditierer bin, der zudem die Räume in einzelne CFG's gesplittet hat (per Include eingebunden). Bei einem Peering wird zwar der Code des Ziels ins Device geschrieben (in die ext. includierte Datei), aber bei einem UnSet nicht wieder daraus entfernt. Das ist der ganze Haken...
Da ein Direkeditieren hier nicht gerne gesehen wird, will ich das mal nicht als BUG bezeichnen...
Zitat von: Pfriemler am 07 Februar 2018, 21:00:58... "(set gas_count ({[gas_count]+1}))" ...
Nope... Ich habe es durch Probieren nun heraus gefunden. Korrekt ist "(set gas_count {([gas_count]+1)})". Alle anderen Kombinationen generieren Murks. Ist eigentlich schade, das man solche fehlerträchtigen Klimmzüge machen muss anstatt für solche Dinge einfach "set Dummy ++" resp. "set Dummy --" schreiben zu können. Solche Zähler braucht man ja öfter mal ... Bei sowas krieg ich immer die Motten ::)
JA, wenn man sich das Beispiel in der Commander genau ansieht, muss die Berechnung zwar in {}, aber darinnen immer mit einer ( beginnen.
Auf dem Holzweg bist Du aber mit dem Peering in der cfg, in welcher auch immer. peerChan und peerBulk senden Befehle zu Programmierung der Geräte. Den Iststand erfährt FHEM durch die auf Anforderung übertragenen Register und speichert diese in den regLists, die nicht in der fhem.cfg landen. Das Internal peerList ermittelt FHEM im Betrieb. Lediglich eine Kopie davon wird im Attribut peerIDs auch in FHEM.cfg gespeichert. Änderungen am Attribut bleiben daher immer wirkungslos für den Betrieb. Einzige Ausnahme sind virtuelle Buttons oder HM-dummes.
... tja, frach mich nicht; keine Ahnung ...
Tatsache war, das ich den UnSet so oft absenden konnte wie ich will und auch nach mehrmaligem Reset des Thermostaten (Batterie raus, alle drei Tasten festhalten, Batterie rein, warten bis RES im Display erscheint) tauchte immer und immer wieder der Kanal 7 als gepeert auf. Erst als ich die ID des Aktors manuell aus dem Attribut "peerIDs" des Thermostaten entfernt hatte, war Ruhe im Karton.
Da die vergangene und auch die folgenden Nächte als ziemlich kalt angekündigt war/sind, habe ich jetzt den ganzen Kram durch Plan-B ersetzt. Das funktioniert ohne Strom, ohne peering, ohne Zentrale, ohne Sorgen ala "na hoffentlich funktioniert das"... Rein mechanische Sachen haben daher m.E. schon aus Zuverlässigkeitsgründen weiterhin ihre Daseinsberechtigung ...
Zitat von: M_I_B am 08 Februar 2018, 08:31:41
... nach mehrmaligem Reset des Thermostaten (Batterie raus, alle drei Tasten festhalten, Batterie rein, warten bis RES im Display erscheint) tauchte immer und immer wieder der Kanal 7 als gepeert auf.
Wenn FHEM das Gerät noch aus früheren Zeiten kennt, ordnet es bekannte Werte umgehend zu. Es wurde durch den Reset ja nicht aus FHEM gelöscht. Freilich sind diese Werte veraltet und erst nach einem erfolgreichen (!) "getConfig" wieder korrekt. Das wiederum funktioniert natürlich erst, wenn das resettete Gerät gepairt wurde - vorher ignoriert es den Befehl zur Datenübermittlung.
Wenn man die Zusammenhänge immer schön im Hinterkopf behält, kann auch nichts wirklich schiefgehen, außer dass es mal einen Knoten in der Kommunikation gibt.
Und Befehle zur Programmierung abzusetzen macht in der Regel nur Sinn, wenn der Command Queue leer ist. Notfalls mit "clear msgEvents" zuvor löschen.
Sonst wird der Knoten nicht kleiner.