Probleme mit HM-CC-RT-DN, Register setzen

[tatus1969]

Hallo,

ich habe eine Installation mit Raspberry + CUL und Homematic-Thermostaten. Ein Schalter an der Haustür soll zur An/Abwesenheitssteuerung genutzt werden. Bei Abwesenheit sollen alle Thermostate auf 15°C gesetzt werden, bei Rückkehr soll das normale Tag/Nachtprogramm wieder aufgenommen werden. Die Thermostate arbeiten im automen Betrieb mit Temperaturlisten.

Um das zu realisieren, möchte ich gerne das Register "tempMax" im Clima-Kanal aller Thermostate manipulieren. Abwesenheit -> set xx_Clima regSet tempMax 15. Anwesenheit ->set xx_Clima regSet tempMax 30. Funktioniert super, außer dass es nicht zuverlässig ist. In manchen Fällen bekomme ich die Fehlermeldung "
cannot calculate value. Please issue set xx_Clima getConfig first - invalid ". Ich habe probiert, das immer vor der dem Registersetzen zu machen - mit dem Ergebnis, dass der Fehler dann immer kommt. Ansonsten tritt der Fehler manchmal auf, und manchmal nicht.

Ich habe etwas tiefer in die Perl-Skripte reingeschaut, und herausgefunden, dass der Sub CUL_HM_getRegFromStore($$$$@) aus 10_CUL_HM.pm diesen Fehler erzeugt, wenn das Register nicht in der Liste zum Gerät zu finden ist.

Wenn ich den Code richtig verstehe, würde es wohl helfen, für den Kanal des Gerätes ein Shadowregister anzulegen. Gür das Gerät selbst gibt es diesen, nicht aber für die einzelnen Kanäle.

Viele Grüße
Frank Böh

[martinp876]

Hallo Frank,

Register setzen:
einige Register sind fractional-byte (Bitfelder) - die können nur manipuliert werden, wenn der rest des Bytes bekannt ist. Es muss also erst die Registerliste gelesen werden/worden sein.
Es nutzt demnach nichts, die Kommandos der reihe nach einzugeben, sondern das getConfig muss erst ausgeführt worden sein, bevor das entsprechende set abgesetzt werden kann.

Shadowreg existieren nur dann, wenn es noch unbestätigte werte gibt, als geänderte Register ohne "rücklesen". shadowreg werden automatisch gelöscht (sind nur hilfsvariablen).

Einfach lässt sich das ganze nicht umgehen, ohne es komplett verwirrend zu machen. Vielleicht fällt mir etwas ein - eine Art known-good-config speichern/lesen.... was aber wenn das Device einen anderen Wert beinhaltet?....

Temp beim Verlassen der Wohnung
register ändern halten ich nicht für geschickt in deinem Anwendungsfall. Der RT bietet doch einen remote-channel genau für diesen Zweck. Wenn du einen HM schalter nutzt peere ihn mit allen deinen RTs.

dann setze in den RTs die Aktion
set <rt>_remote regSet lgCtrlRc tempOnly <myBtnName>
set <rt>_remote regSet lgTempRC 15 <myBtnName>

set <rt>_remote regSet shCtrlRc auto <myBtnName>
#set <rt>_remote regSet shTempRC 15 <myBtnName>

3: lgCtrlRc     | literal    | set mode and/or temperature options:tempOnly,toggle,manuAndTemp,autoAndTemp,auto,boost,no
3: lgTempRC  | 5 to 30C | temperature repated to CtrlRc reg

3: shCtrlRc     |   literal   | set mode and/or temperature options:tempOnly,toggle,manuAndTemp,autoAndTemp,auto,boost,no
3: shTempRC  | 5 to 30C| temperature repated to CtrlRc reg

Du kannst also langen und kurzen tastendruck separat belegen.
toggle habe ich nicht probiert - ist vielleicht das was du suchtst?

Gruss Martin

[tatus1969]

Hallo Martin,

Register setzen:
okay, den Mechanismus verstehe ich. Was hältst Du von meiner Ideen dazu: der Ablauf wird davon abhängig gemacht, ob ein Register Teil eines Bitfeldes ist oder nicht. Wenn nicht (wie in meinem Fall [?]), wird das Abfragen des bekannten Wertes unterdrückt weil nicht notwendig. Wenn doch, dann werden automatisch die nötigen Registerteile vom Device abgefragt sofern unbekannt, und sofern das möglich ist. Letzteres würde ja momentan ohnehin gemacht werden müssen.

Was ich nicht ganz verstehe ist, dass während meiner Versuche in der Webansicht des (xx_Clima) Devices zu jeder Zeit ein Wert angezeigt wurde. Kann es sein, dass das Aktualisieren eines Registers mittels regSet dazu führt, dass fhem-intern dieses Register als invalide markiert wird, so lange, bis die Übertragung mit einem ACK abgeschlossen ist? Wenn das so ist, ist das sinnvoll? Ich finde, sobald mindestens einmal alle Register bekannt sind, sollten diese dauerhaft valide bleiben. Zumindest bei Devices mit Rückkanal wie Homematic. Es könnte ja der alte Wert gespeichert bleiben, solange bis eine gültige Rückantwort gekommen ist.

Alternativ: mir ist nicht klar, wie ich ein Perl-skript so gestalten kann, dass es getConfig ausführt, dann auf dessen Beendigung wartet, und dann die Register schreibt. Ich habe daran gedacht, diese Teile per at zeiversetzt auszulösen, nur ist die Zeitdauer für einen so komplexen Vorgang wie 9xgetConfig schwer abzuschätzen. Außerdem geht das spätestens dann schief, wenn mann schnell hintereinander auf die beiden Buttons (es ist ein Homematic-Taster mit Auf-Ab-Wippe, die getrennt ausgewertet und übermittelt wird) drückt (zb aus Versehen gedrückt).

Wohnung verlassen
das werde ich ausprobieren, leider hat das für mich mehrere Haken weshalb ich es nicht so lösen wollte:
- es sind 9 Thermostate, können soviele überhaupt angelernt werden, und was sagt die Batterie auf Dauer dazu
- die Steuerung soll auch über das Web möglich sein

Ist es denn auch möglich, den Remote-Kanal durch FHEM zu steuern? Das scheint mir gerade die einfachste Lösung zu sein. Ich werde heute abend versuchen, ein Peering zu machen und herauszufinden wie der nötige FHEM-Befehl aussieht.

Danke schonmale für Deine Hilfe, so langsam wird das Ganze rund!

Nur der Vollständigkeit halber: FHEM auf Raspberry PI, selbstgebaute Erweiterungskarte mit Spannungsregler / CSM-Modul / 3digout / 4digin / 2analogout / 8analogin / Audioverstärker in Arbeit, Stetigsteuerung einer Junkers-Gastherme mit Vorlauftemperaturregelung und Abschaltung Umwälzpumpe (Sommer) / Abschaltung Warmwasserbereitung (nachts), Ermittlung der Vorlaufsolltemperatur über größte Regeldifferenz aller Thermostate, 9 HM-CC-RT-DN Thermostate, globaler Abwesenheitsschalter, Fensterkontakte, geplant: Rauchmelder.

Viele Grüße
Frank

[martinp876]

Hi Frank,

Wenn doch, dann werden automatisch die nötigen Registerteile vom Device abgefragt sofern unbekannt, und sofern das möglich ist. Letzteres würde ja momentan ohnehin gemacht werden müssen.

wenig. Das erzeugt ziemlich lange sequenzen - ausserdem muss ich auch noch eine Command-queue einbauen, bisher gibt es nur eine message-queue. Das ganze wird recht komplex... Das ist eigentlich ein layer oberhalb von CUL_HM.

Kann es sein, dass das Aktualisieren eines Registers mittels regSet dazu führt, dass fhem-intern dieses Register als invalide markiert wird, so lange, bis die Übertragung mit einem ACK abgeschlossen ist?

nicht beim Setzen sondern vor dem Lesen werden die roh-register gelöscht. Wenn das Lesen schief geht habe ich keine mehr. Halte ich für gerechtfertigt, da ich nicht mit gutem Gewissen auf die alten Werte zurückfallen kann.

Ich finde, sobald mindestens einmal alle Register bekannt sind, sollten diese dauerhaft valide bleiben

und wenn sie geändert werden?

Alternativ: mir ist nicht klar, wie ich ein Perl-skript so gestalten kann...

Prinzipiell ist mir das Problem klar. Ich sehe 2 facetten:
a) getConfig ging schief - oder: die Registerlisten sind nicht komplett. Ich plane ein AutoReadReg zu erweitern - so dass das lesen der Register immer wieder eingehängt wird, wenn die Listen nicht komplett sind. Wird sicher zeitverzögert sein, und ich werden es nicht als default einbauen
b) config-only devices (remotes) können nicht ausgelesen werden, ohne anlernen. Daher denke ich daran, dass die werte aus einem Registerfile nachgeladen werden können. Man kann die Register ja schon in ein File schreiben - jetzt könnte man es zurücklesen... zusammen mit a) wäre es ziemlich komplett glaube ich. Ich muss noch über die Darstellung nachdenken, das User interface generell. Am Ende muss es verständlich sein.

- es sind 9 Thermostate, können soviele überhaupt angelernt werden, und was sagt die Batterie auf Dauer dazu

Anlernen sollte bei einer Remote kein Problem sein. Wie viele Burst-starts gesendet werden kann ich nicht sagen. Die Batterie der remote sollte kein Problem sein.

Ist es denn auch möglich, den Remote-Kanal durch FHEM zu steuern?

klar - baue einen virtuellen Button und paire diesen mit allen RT_Remotes.
hm - da könnte/sollte man dann noch sparen... FHEM würde/müsste bursts schicken.

Code Auswählen Erweitern

set vb_Btn1 press short oder long
In deinem Fall wäre es aber nicht sinnvoll/nötig, man könnte das ganze auch einfach in die Queue stecken und warten, bis der RT aufwacht.
Ich werden einbauen

set vb_Btn1 press noBurst

du kannst press im Anhang probieren

Gruss Martin

[martinp876]

Hi Frank,

ich habe eine getestet Version eingecheckt
4573

das Kommando ist dann
set (Button) press short noBurst

Gruss Martin

[martinp876]

würde es reichen, die Registerteile automatisch zu lesen, die zu den betroffenen Bitfeldern fehlen?

man kann nur ganze listen lesen

Vielleicht lohnt es sich ja, bei Registern, die ganze Bytes belegen, eine spezielle Behandlungsweise einzuführen, die nicht auf "alte" Werte angewiesen ist.

das ist schon immer so.

Zur Command-queue: das Argument verstehe ich. Klingt nach einer größeren OP am offenen Herzen

es ist eine ganz andere Qualität. Könnte man machen, aber sollte es nicht auf dieser Ebene realisieren.

Okay. Dann verstehe ich aber das Fehlerbild hier bei mir nicht mehr

1. getConfig -> roh-register werden gelöscht UND gelesen. Sollte das Lesen schief gehen habe ich keine roh-daten mehr. Die ausgewerteten Register bleiben stehen.
2. regSet -> prüft, ob eine Änderung notwendig ist. Geschrieben wird nur eine differenz zu den gelesenen werten. Wenn keine Werte vorhanden sind UND es ein ganzes Byte ist wird immer geschrieben. Es wird ein shadowreg angelegt mit den Änderungen. Das shadowreg wird auch beim lesen gelöscht (jetzt kommen ja hoffentlich die realen Daten)

wenn FHEM einmal per getConfig alle Register erhalten hat, sollte danach nicht dauerhaft ein gültiger Zustand erhalten bleiben, in dem jederzeit beliebige regSet erlaubt sind?

was ist 'einmal gelesen' und wie lange ist es gültig? Sonderfälle sind reset, lokale programmierung (RT/TC,...). Mit jeden regSet muss sowieso wieder geprüft werden, ob es funktioniert hat - manche devices haben ein eigenleben...
Und wo soll ich es speichern? Readings werden von Zeit zu Zeit gelöscht, je nach restart typ. Attribute sind hinderlich, da nach jeder Änderung ein save notwendig wäre (und andere Probleme).
HM ist nur ein kleiner Teil von FHEM - und andere scheinen das Problem nicht zu haben.

Wenn FHEM eine externe Registeränderung nicht mitschneidet

FHEM schneidet mit. Verloren gegangene Messages sind immer ein Problem...

Ich denke hier aber auch, das ist nicht Aufgabe des CUL_HM Layers. Eher sicherzustellen, dass alle Befehle zuverlässig ausgeführt werden.

verstehe ich nicht. Die werte müssen errechnet werden. Wenn der CUL_HM layer keine register-auswertung machen soll (kann man so sehen) kannst du regBulk nutzen. damit kannst du alles schreiben, was möglich ist - und es selbst errechnen. Wenn CUL_HM den service bietet muss es auch die Werte errechnen - und braucht eine Basis.
Und beachte: Ich bin mir sicher dass es einige undokumentierte bitfelder gibt. Die kannst du auch ändern  - was dann passiert ist deine Sache. CUL_HM regSet ändert, was in der spec steht.

autoReadReg ist für diesen Kanal (xx_Clima) nicht aktiviert, sonden nur für das Gerät selbst

HM attribute am device gelten auch für dessen Channels, sofern der Channel nicht ein eigenes hat. Daher wird es automatisch nur am Device vergeben.

Nach dem Fehlerbild oben bin ich mir nicht sicher, dass diese Erweiterungen helfen würden.

ich denke schon. Bislang kann man readings oder register-readings löschen oder sie werden automatisch gelöscht. Das Attribut wird nicht in nullzeit reagieren können - bei einem TC/RT... kann es Minuten dauern. FHEM kann jetzt schon prüfen, dass alle vollständigen Registerlisten vorhanden sind. Das ganze wird "weich" eingebaut um Überlast des HMLAN zu vermeiden - und anderes. Da aber registerlisten nicht ständig gelöscht werden sollte es kein Problem sein. Sicher muss ich einbauen "keine toten Devices zu reiten". Da muss ein striktes sendelimit eingebaut werden, sonst töten wir FHEM!

set Haus_Unbewohnt peerChan 1 Schlafzimmer_Thermostat_remote single

die '1' kannst du weg lassen. Der Parameter ist veraltet und dafür vorgesehen, wenn Haus_Unbewohnt ein device ist. die '0' ist ein dummy wenn die primäre Entity ein channel ist.

Jetzt kann ich im Webinterface einen Button drücken ("set Haus_Unbewohnt press"

das kannst du mitschneiden -
http://forum.fhem.de/index.php/topic,16563.msg107848.html#msg107848

Gruss Martin

[tatus1969]

das ist schon immer so.

Ich bin mittlerweile einigermaßen verloren, was den Überblick angeht. Aber heißt das für mich, dass das "tempMax" Register des HM-CC-RT-DN Teil eines Bitfeldes ist?

1. getConfig -> roh-register werden gelöscht UND gelesen. Sollte das Lesen schief gehen habe ich keine roh-daten mehr. Die ausgewerteten Register bleiben stehen.
2. regSet -> prüft, ob eine Änderung notwendig ist. Geschrieben wird nur eine differenz zu den gelesenen werten. Wenn keine Werte vorhanden sind UND es ein ganzes Byte ist wird immer geschrieben. Es wird ein shadowreg angelegt mit den Änderungen. Das shadowreg wird auch beim lesen gelöscht (jetzt kommen ja hoffentlich die realen Daten)

Wenn das so ist, wie kann dann wiederholtes regSet zu diesem Fehler führen? (ich brauche getConfig nicht, um den Fehler zu provozieren, wiederholtes regSet reicht...) Oder heißt das, dass ein Fhem automatisch nach einem regSet ein getConfig durchführt?

HM ist nur ein kleiner Teil von FHEM - und andere scheinen das Problem nicht zu haben.

Die Lösung virtueller Button scheint ja der richtige Weg zu sein. Vielleicht hat ja vor mir noch keiner versucht, skriptbasiert Register zu manipulieren. Wenn ich das in der Kommandozeile einzeln mache, kann ich mir ja den Weg zum Ziel irgendwie zurechtbasteln Ansonsten wüsste ich nicht, was ich besonderes oder anders mache...

ich denke schon. Bislang kann man readings oder register-readings löschen oder sie werden automatisch gelöscht. Das Attribut wird nicht in nullzeit reagieren können - bei einem TC/RT... kann es Minuten dauern. FHEM kann jetzt schon prüfen, dass alle vollständigen Registerlisten vorhanden sind. Das ganze wird "weich" eingebaut um Überlast des HMLAN zu vermeiden - und anderes. Da aber registerlisten nicht ständig gelöscht werden sollte es kein Problem sein. Sicher muss ich einbauen "keine toten Devices zu reiten". Da muss ein striktes sendelimit eingebaut werden, sonst töten wir FHEM!

Vielleicht habe ich noch nicht verstanden, wann Registerinhalte automatisch gelöscht werden. Du hast gesagt, das passiert in dem Moment, in dem getConfig gerufen wird. Verstehe ich (oder könnte man die alten Werte solange gültig belassen bis neue angekommen sind). Nur ich rufe in meinem Fall gar kein getConfig auf (nur einmal am Anfang). Es sei denn, wie oben gefragt, ein regSet löst in Folge automatisch ein getConfig aus...


Zum Thema Verhalten regSet/shadow/Bitfelder etc: am Ende schaue ich sowieso nicht tief genug in die Architektur Fhem / Homematic hinein. Mit "das ist nicht Aufgabe des CUL_HM Layers. Eher sicherzustellen, dass alle Befehle zuverlässig ausgeführt werden" habe ich gemeint, dass ich mir nicht vorstellen kann, dass permanente Datenkonsistenz zwischen Fhem und den Geräten bestehen kann. Also muss bei einer Änderungsanforderung "regSet" entweder davon ausgegangen werden, dass die bekannten Daten stimmen, oder dass sie vorher neu gelesen werden müssen wenn sie relevant für den aktuellen Vorgang sind. Das ist, wie ich verstanden habe, ein komplexer Vorgang der so nicht abgebildet ist. Deshalb finde ich die erste Option (fhem geht immer davon aus, dass Konsistenz da ist) nicht die schlechteste. Weil ich dann selbst die Möglichkeit habe, einzugreifen (getConfig an der richtigen Stelle) oder eben nicht, wenn ich weiss, dass sich nichts geändert haben kann. Wie gesagt, meine Gedanken, sicher übersehe ich viele Details dabei.



1. getConfig -> roh-register werden gelöscht UND gelesen. Sollte das Lesen schief gehen habe ich keine roh-daten mehr. Die ausgewerteten Register bleiben stehen.
2. regSet -> prüft, ob eine Änderung notwendig ist. Geschrieben wird nur eine differenz zu den gelesenen werten. Wenn keine Werte vorhanden sind UND es ein ganzes Byte ist wird immer geschrieben. Es wird ein shadowreg angelegt mit den Änderungen. Das shadowreg wird auch beim lesen gelöscht (jetzt kommen ja hoffentlich die realen Daten)
was ist 'einmal gelesen' und wie lange ist es gültig? Sonderfälle sind reset, lokale programmierung (RT/TC,...). Mit jeden regSet muss sowieso wieder geprüft werden, ob es funktioniert hat - manche devices haben ein eigenleben...
Und wo soll ich es speichern? Readings werden von Zeit zu Zeit gelöscht, je nach restart typ. Attribute sind hinderlich, da nach jeder Änderung ein save notwendig wäre (und andere Probleme).
HM ist nur ein kleiner Teil von FHEM - und andere scheinen das Problem nicht zu haben.
FHEM schneidet mit. Verloren gegangene Messages sind immer ein Problem...
verstehe ich nicht. Die werte müssen errechnet werden. Wenn der CUL_HM layer keine register-auswertung machen soll (kann man so sehen) kannst du regBulk nutzen. damit kannst du alles schreiben, was möglich ist - und es selbst errechnen. Wenn CUL_HM den service bietet muss es auch die Werte errechnen - und braucht eine Basis.
Und beachte: Ich bin mir sicher dass es einige undokumentierte bitfelder gibt. Die kannst du auch ändern  - was dann passiert ist deine Sache. CUL_HM regSet ändert, was in der spec steht.
HM attribute am device gelten auch für dessen Channels, sofern der Channel nicht ein eigenes hat. Daher wird es automatisch nur am Device vergeben.
ich denke schon. Bislang kann man readings oder register-readings löschen oder sie werden automatisch gelöscht. Das Attribut wird nicht in nullzeit reagieren können - bei einem TC/RT... kann es Minuten dauern. FHEM kann jetzt schon prüfen, dass alle vollständigen Registerlisten vorhanden sind. Das ganze wird "weich" eingebaut um Überlast des HMLAN zu vermeiden - und anderes. Da aber registerlisten nicht ständig gelöscht werden sollte es kein Problem sein. Sicher muss ich einbauen "keine toten Devices zu reiten". Da muss ein striktes sendelimit eingebaut werden, sonst töten wir FHEM!
die '1' kannst du weg lassen. Der Parameter ist veraltet und dafür vorgesehen, wenn Haus_Unbewohnt ein device ist. die '0' ist ein dummy wenn die primäre Entity ein channel ist.


Hier ist ein kurzer Mitschnitt. Ich habe alles dringelassen, ich weiss nicht ob es hierfür eine Rolle spielt. Es scheint so als würde der Thermostat überhaupt nicht antworten. Ich hatte beim letzten Post vergessen zu erwähnen, dass ich meine fhem.cfg angehängt hatte.

Viele Grüße
Frank

----------------

2014.01.08 16:35:09.327 2: CUL_HM set Haus_Unbewohnt press
2014.01.08 16:35:09.346 4: SND L:0B N:01 F:A4 CMD:40 SRC:SystemButtons DST:Schlafzimmer_Thermostat 0401 (REMOTE BUTTON:0x04 LONG:0x04 LOWBAT:0x04 COUNTER:0x01) (,CFG,BIDI,RPTEN)
2014.01.08 16:35:10.485 4: CUL_HM_Resend: SystemButtons nr 2
2014.01.08 16:35:11.965 4: RCV L:0C N:D1 F:86 CMD:70 SRC:Heizung_Vorlauftemperatur DST:broadcast 016A64 (WeatherEvent TEMP:0x016A HUM:0x64) (,WAKEMEUP,CFG,RPTEN)
2014.01.08 16:35:15.412 4: CUL_HM_Resend: SystemButtons nr 3
2014.01.08 16:35:22.145 4: CUL_HM_Resend: SystemButtons nr 4
2014.01.08 16:35:39.167 4: RCV L:0F N:47 F:86 CMD:10 SRC:WohnzimmerRechts_Thermostat DST:broadcast 0AA8DF0F2D01 (INFO_TEMP SET:0xA8DF ACT:0xA8DF ERR:0x0F VALVE:0x0F MODE:0x0F) (,WAKEMEUP,CFG,RPTEN)
2014.01.08 16:35:48.648 4: RCV L:0F N:CA F:86 CMD:10 SRC:Flur_Thermostat DST:broadcast 0AA0D3102414 (INFO_TEMP SET:0xA0D3 ACT:0xA0D3 ERR:0x10 VALVE:0x10 MODE:0x10) (,WAKEMEUP,CFG,RPTEN)
2014.01.08 16:35:49.930 2: CUL_HM set Heizungssteller_Sw 100.0
2014.01.08 16:35:49.949 4: SND L:10 N:02 F:A0 CMD:11 SRC:F11234 DST:Heizungssteller 0201C80320FFFF (SET CHANNEL:0x01 VALUE:0xC8 RAMPTIME:0x0320 DURATION:0xFFFF) (,BIDI,RPTEN)
2014.01.08 16:35:50.090 4: RCV L:0F N:02 F:80 CMD:02 SRC:Heizungssteller DST:F11234 0101C80025EC (ACK_STATUS CHANNEL:0x01 STATUS:0xC8 UP:0x00 DOWN:0x00 LOWBAT:0x00 RSSI:0x25) (,RPTEN)
2014.01.08 16:35:51.979 4: RCV L:0F N:2A F:86 CMD:10 SRC:BadUnten_Thermostat DST:broadcast 0A98CE10182B (INFO_TEMP SET:0x98CE ACT:0x98CE ERR:0x10 VALVE:0x10 MODE:0x10) (,WAKEMEUP,CFG,RPTEN)
2014.01.08 16:35:55.271 4: RCV L:0F N:03 F:A4 CMD:10 SRC:Heizungssteller DST:F11234 0601C80080C8 (INFO_ACTUATOR_STATUS RSSI:0x80 CHANNEL:0x01 STATUS:0xC8 UNKNOWN:0x00) (,CFG,BIDI,RPTEN)
2014.01.08 16:35:55.376 4: SND L:0A N:03 F:80 CMD:02 SRC:F11234 DST:Heizungssteller 00 (ACK) (,RPTEN)
2014.01.08 16:36:25.350 4: RCV L:0F N:9C F:86 CMD:10 SRC:WohnzimmerLinks_Thermostat DST:broadcast 0AA8DF0F2E14 (INFO_TEMP SET:0xA8DF ACT:0xA8DF ERR:0x0F VALVE:0x0F MODE:0x0F) (,WAKEMEUP,CFG,RPTEN)
2014.01.08 16:36:26.523 4: RCV L:0F N:EE F:86 CMD:10 SRC:Ole_Thermostat DST:broadcast 0A98C0103218 (INFO_TEMP SET:0x98C0 ACT:0x98C0 ERR:0x10 VALVE:0x10 MODE:0x10) (,WAKEMEUP,CFG,RPTEN)
2014.01.08 16:36:38.299 4: RCV L:0F N:43 F:86 CMD:10 SRC:Jesse_Thermostat DST:broadcast 0A98C6101618 (INFO_TEMP SET:0x98C6 ACT:0x98C6 ERR:0x10 VALVE:0x10 MODE:0x10) (,WAKEMEUP,CFG,RPTEN)
2014.01.08 16:36:49.940 2: CUL_HM set Heizungssteller_Sw 100.0
2014.01.08 16:36:49.959 4: SND L:10 N:03 F:A0 CMD:11 SRC:F11234 DST:Heizungssteller 0201C80320FFFF (SET CHANNEL:0x01 VALUE:0xC8 RAMPTIME:0x0320 DURATION:0xFFFF) (,BIDI,RPTEN)
2014.01.08 16:36:50.101 4: RCV L:0F N:03 F:80 CMD:02 SRC:Heizungssteller DST:F11234 0101C80025EC (ACK_STATUS CHANNEL:0x01 STATUS:0xC8 UP:0x00 DOWN:0x00 LOWBAT:0x00 RSSI:0x25) (,RPTEN)
2014.01.08 16:36:54.827 4: RCV L:0F N:04 F:A4 CMD:10 SRC:Heizungssteller DST:F11234 0601C80080C8 (INFO_ACTUATOR_STATUS RSSI:0x80 CHANNEL:0x01 STATUS:0xC8 UNKNOWN:0x00) (,CFG,BIDI,RPTEN)
2014.01.08 16:36:54.927 4: SND L:0A N:04 F:80 CMD:02 SRC:F11234 DST:Heizungssteller 00 (ACK) (,RPTEN)
2014.01.08 16:36:55.972 4: RCV L:0F N:B2 F:86 CMD:10 SRC:Lennart_Thermostat DST:broadcast 0AA0D30F2B18 (INFO_TEMP SET:0xA0D3 ACT:0xA0D3 ERR:0x0F VALVE:0x0F MODE:0x0F) (,WAKEMEUP,CFG,RPTEN)
2014.01.08 16:37:04.025 4: RCV L:0F N:3B F:86 CMD:10 SRC:Schlafzimmer_Thermostat DST:broadcast 0A90BA100118 (INFO_TEMP SET:0x90BA ACT:0x90BA ERR:0x10 VALVE:0x10 MODE:0x10) (,WAKEMEUP,CFG,RPTEN)

[martinp876]

dass das "tempMax" Register des HM-CC-RT-DN Teil eines Bitfeldes ist?

korrekt - ist nur 6 Bit lang

Oder heißt das, dass ein Fhem automatisch nach einem regSet ein getConfig durchführt?

Wenn autoReadReg 4 gesetzt ist wird gelesen - das ist ein implizites getConfig -  wie auch sonst?  Es gibt nur ein lesen. Nur dass es "sanft" verzögert wird (gelöscht wird esrt beim absetzen des Kommandos)

wann Registerinhalte automatisch gelöscht werden

Registerinhalte oder RegisterReadings ? Inhalte (im HM device) kann man nur schreiben, readings kann man löschen.

oder könnte man die alten Werte solange gültig belassen bis neue angekommen sind

wäre wohl machbar. werde es einmal auf meine Liste setzen. Ist aber unschön - das heisst, dass das lesen schief gegangen ist. Das sollte wiederholt werden. Es löst auch nicht alle Fälle.

dass permanente Datenkonsistenz zwischen Fhem und den Geräten bestehen kann

Korrekt. Die Idee ist: was gelesen wurde ist korrekt. Sollte eine Änderung auftauchen werden die Daten erneuert oder gelöscht. Keine Daten sind besser als falsche Daten. Ich geben zu, dass es  nicht 100% eingehalten wird... z.B. nach restarts alles lesen und so. Da verlasse ich mich auf das Statefile und dessen Mechanismus zu löschen.

dass die bekannten Daten stimmen, oder dass sie vorher neu gelesen werden müssen

stimme ich nicht zu. Jedes auch nur halbwegs zuverlässige system MUSS den User hier unterstützen. Wenn daten fehlen ist es besser NICHT zu schreiben sondern den User zu "alarmieren". Das ist der aktuelle Stand. Welche Daten noch als relevant gelten kann man diskutieren, mehr nicht.

fhem geht immer davon aus, dass Konsistenz da ist

wennkeine Daten da sind,sind sie nicht konsistent. Wenn lesen schief geht, stimmt etwas nicht - action required. Ging das schreiben gut?...
Konsistenz muss gewissen Kriterien genügen.

Du kannst das automatische update ausschalten und alles manuell machen. Einfach autoReadReg abschalten und du hast das neu Lesen in deiner Hand.

Zum virtuellen button:
hast du die neuste Version von FHEM? Da gibt es änderungen dazu.

Die Nächste version wird ein autoReadReg 5 anbieten. Da wird geprüft, ob die register "komplett" sind und ggf  noch einmal gelesen. Die erneute Prüfung kommt aber erst nach 30min um nichts zu überlasten
wird heute Abend eingelagert

Gruss Martin


p.s.habe noch einmal nachgedacht - das löschen der roh-register zum getConfig-start ist schon nicht so schlecht. Wenn jemand das Kommando absetzt (auch implizit) erwartet er, dass die zu lesenden Daten korrekt und neu sind. Wenn sie noch nicht gelesen sind, ist das eben nicht der Fall. Viele glauben immer wieder ein getConfig gefolgt von einem regSet abzusetzen - das ist definitiv irreführend und MUSS zu einen Fehler führen (bei Bitfeldern!)

[tatus1969]

Wenn autoReadReg 4 gesetzt ist wird gelesen - das ist ein implizites getConfig -  wie auch sonst?

Damit ist mir ein Licht aufgegangen und ich verstehe was Du mir die ganze Zeit sagen willst! Das erklärt das Verhalten, und gibt mir auch die Lösung an die Hand. Ich habe autoReadRegs jetzt auf 2 gestellt, damit habe ich es in der Hand, wann ich RegisterReadings in fhem aktualisiere, und wann ich Register in den Geräten ändere. Mal schauen was passiert, jetzt mache ich erstmal Feierabend. Tja, manchmal hilft nur RTFM, das hatte ich überlesen. Steht ja auch viel drin in der Doku (soll heißen: Wahnsinnsarbeit die Du da hingelegt hast)

Registerinhalte oder RegisterReadings

In dem Fall Readings. Gar nicht so einfach da eindeutig zu sein...

p.s.habe noch einmal nachgedacht - das löschen der roh-register zum getConfig-start ist schon nicht so schlecht.

Dachte ich im Nachhinein auch noch. Ansonsten hat man keinen Hinweis, ob man irgendwo einen alten oder einen neuen Wert stehen hat.

stimme ich nicht zu. Jedes auch nur halbwegs zuverlässige system MUSS den User hier unterstützen. Wenn daten fehlen ist es besser NICHT zu schreiben sondern den User zu "alarmieren". Das ist der aktuelle Stand. Welche Daten noch als relevant gelten kann man diskutieren, mehr nicht.
wennkeine Daten da sind,sind sie nicht konsistent. Wenn lesen schief geht, stimmt etwas nicht - action required. Ging das schreiben gut?...
Konsistenz muss gewissen Kriterien genügen.

So war das nicht gemeint. Mein Kommentar bezog sich auf die Möglichkeit einer Commandqueue, wobei automatisch fehlende Infos reingeholt werden. Als Overkill verworfen...

Zum virtuellen button:
hast du die neuste Version von FHEM? Da gibt es änderungen dazu.

Ich hoffe schon. Wenn ich update all eingebe, wird nichts gemacht (update nothing to do...) und Fhem meldet Version 5.5 (DEVELOPMENT). 10_CUL_HM.pm habe ich einzeln aktualisiert, die Funktion press noBurst ist vorhanden.

[martinp876]

Wenn ich update all eingebe, wird nichts gemacht (update nothing to do...) und Fhem meldet Version 5.5 (DEVELOPMENT). 10_CUL_HM.pm habe ich einzeln aktualisiert, die Funktion press noBurst ist vorhanden.

5.5 ist eine sehr ungenaue Angabe. Machen ein "version".
update geht meistens - machmal(selten) hat es sich verrannt (meine Platte war einmal voll beim Update) - dann klappt update nicht mehr normal, du musst dann einen update force machen.
aber bei dir scheint zumindest CUL_HM ok wenn noBurst angeboten wird

[tatus1969]

Version vor update:

# $Id: fhem.pl 4386 2013-12-15 17:09:05Z rudolfkoenig $
# $Id: 00_CUL.pm 4389 2013-12-16 06:47:56Z rudolfkoenig $
# $Id: 10_CUL_HM.pm 4573 2014-01-06 13:41:57Z martinp876 $
# $Id: 01_FHEMWEB.pm 4384 2013-12-15 10:45:37Z rudolfkoenig $
# $Id: 92_FileLog.pm 3759 2013-08-21 08:13:08Z rudolfkoenig $
# $Id: 98_PID.pm 4086 2013-10-21 18:21:09Z betateilchen $
# $Id: 99_SUNRISE_EL.pm 3738 2013-08-18 14:13:59Z rudolfkoenig $
# $Id: 98_SVG.pm 4384 2013-12-15 10:45:37Z rudolfkoenig $
# $Id: 99_Utils.pm 3595 2013-08-05 05:38:48Z tobiasfaust $
# $Id: 59_Weather.pm 4321 2013-12-03 20:13:08Z borisneubert $
# $Id: 90_at.pm 4246 2013-11-18 20:35:20Z rudolfkoenig $
# $Id: 98_autocreate.pm 4234 2013-11-17 10:19:41Z rudolfkoenig $
# $Id: 98_dummy.pm 3738 2013-08-18 14:13:59Z rudolfkoenig $
# $Id: 91_eventTypes.pm 2982 2013-03-24 17:47:28Z rudolfkoenig $
# $Id: 91_notify.pm 3738 2013-08-18 14:13:59Z rudolfkoenig $
# $Id: 98_telnet.pm 3738 2013-08-18 14:13:59Z rudolfkoenig $

Update force gemacht, danach schaut es so aus:

# $Id: fhem.pl 4565 2014-01-05 22:17:37Z rudolfkoenig $
# $Id: 00_CUL.pm 4530 2014-01-02 13:56:09Z rudolfkoenig $
# $Id: 10_CUL_HM.pm 4573 2014-01-06 13:41:57Z martinp876 $
# $Id: 01_FHEMWEB.pm 4586 2014-01-07 11:48:46Z rudolfkoenig $
# $Id: 92_FileLog.pm 4574 2014-01-06 14:12:42Z rudolfkoenig $
# $Id: 98_PID.pm 4086 2013-10-21 18:21:09Z betateilchen $
# $Id: 99_SUNRISE_EL.pm 4537 2014-01-03 08:28:59Z rudolfkoenig $
# $Id: 98_SVG.pm 4503 2013-12-29 18:38:50Z rudolfkoenig $
# $Id: 99_Utils.pm 3595 2013-08-05 05:38:48Z tobiasfaust $
# $Id: 59_Weather.pm 4321 2013-12-03 20:13:08Z borisneubert $
# $Id: 90_at.pm 4246 2013-11-18 20:35:20Z rudolfkoenig $
# $Id: 98_autocreate.pm 4234 2013-11-17 10:19:41Z rudolfkoenig $
# $Id: 98_dummy.pm 3738 2013-08-18 14:13:59Z rudolfkoenig $
# $Id: 91_eventTypes.pm 2982 2013-03-24 17:47:28Z rudolfkoenig $
# $Id: 91_notify.pm 3738 2013-08-18 14:13:59Z rudolfkoenig $
# $Id: 98_telnet.pm 3738 2013-08-18 14:13:59Z rudolfkoenig $

Jetzt klappts! update force... muss man auch wissen Damit sollte meiner Ausserhaus-Funktion nichts mehr im Weg stehen.

Vielen Dank Martin!

Grüße
Frank