mal wieder ein peering - Problem :(

[M_I_B]

... 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...)

[frank]

der 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.

[M_I_B]

... 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!

[Pfriemler]

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.

[M_I_B]

... 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:

Code Auswählen Erweitern

### 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?

[M_I_B]

... 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 

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 ...

[Pfriemler]

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

Berechnungen 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.

[martinp876]

Was passiert, wenn nach den Kommandos nix passiert.?
Fehlerhafte messages? Pending? Abbrüche?

[M_I_B]

... 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...

... "(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 

[Pfriemler]

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.

[M_I_B]

... 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 ...

[Pfriemler]

... 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.