Hallöchen,
ich wollte grad ein paar Werte an den Thermostaten ändern und habe festgestellt, dass wenn ich die Hilfe von RegSet umsetze, nämlich:
ZitatUnterstützte Register eines Geräts können wie folgt bestimmt werden:
set regSet ? 0 0
Gibts einen schönen satten Absturz, wenn ich genau diesen Befehl eingebe. Gefolgt von einem
Quantifier follows nothing in regex; marked by <-- HERE in m/? <-- HERE / at ./FHEM/10_CUL_HM.pm line 4596.im Log.
Da es mein Live System ist, würde ich jetzt nicht zwingend mehrmals die Reproduzierbarkeit testen wollen, aber wenn ich da zur Fehlerfinden beitragen kann, sagt bescheid :)
Viele Grüße
Andreas
Moin,
ich kann das bestätigen. Ich habe den Befehl noch nie verwendet, aber ein Test zeigt sofort die beschriebene Wirkung.
Gruß Otto
ein "get regTable" führt bei einem user ebenfalls zum absturz.
Zitathttps://forum.fhem.de/index.php/topic,18071.msg1095541.html#msg1095541
@flummy1978
zum ändern von registern empfehle ich
hm.js.
siehe link in meiner signatur.
Danke frank,
das werde ich mir anschauen, sobald ich mein aktuelles Lag Problem gelöst habe. Vielen Dank für den Hinweis :)
Viele Grüße
Andreas
A) ist korrigiert - morgen im Download
1) Absturz geht nicht - muss korrigiert werden
2) Funktion ist zugesichert - also realisiert
3) Problem war das Sonderzeichen "?" welches nicht straight verglichen wird
4) die Funktion regSet ? 0 0 ist eine schwache Hilfe. Faktisch wird als Register "?" eingebeben welches nicht existiert. Man könnte also auch regSet x 0 0 eingeben - gleicher effekt
5) will man registerlisten sehen ist ein get regList deutlich sinnvoller. Oder auch regTable
6) die Nutzung von hm.js ist sehr elegant
Hallo Martin,
ZitatA) ist korrigiert - morgen im Download
führt zu https://forum.fhem.de/index.php/topic,115457.0.html (https://forum.fhem.de/index.php/topic,115457.0.html).
Zitat1) Absturz geht nicht - muss korrigiert werden
in Rev 23058 nur den Metacharacters ein \ voranzustellen, anstatt allen, sollte helfen.
$foo =~ s/([\\^.$|()[\]*+?{}\-#])/\\$1/g;(wenn ich keinen übersehen habe)
statt
$foo =~ s/(.)/\\$1/g;Gruß, Ansgar.
:)Moin, bestätigt, alte 10_CUL_HM.pm recovery, läuft wieder.
Moin zusammen,
der FHEM Server startet nach Änderungen der Temperatureinstellungen neu.
Ich habe die alte Version von letzter Woche zurück geladen.
Gruß Helmut
Bei mir taucht auch noch eine andere neue perl Warnung im Zusammenhang mit CUL_HM auf:
2020.11.01 05:00:00 1: PERL WARNING: Unrecognized escape \y passed through in regex; marked by <-- HERE in m/\d\a\y <-- HERE / at ./FHEM/10_CUL_HM.pm line 4597.
Das dürfte der Theorie mit dem "zuviel escaped" entsprechen. Um 05:00 wird bei mir ein Wandregler (TC) per "set ... controlMode day" umgeschaltet.
Mein FHEM stürzt dadurch aber nicht ab, nur der Befehl wird nicht ausgeführt.
Edit:
Mit der von noansi vorgeschlagenen Änderung funktioniert das Schalten des TC wieder.
Hallo allerseits,
Reference to nonexistent group in regex; marked by <-- HERE in m/\1 <-- HERE \5/ at ./FHEM/10_CUL_HM.pm line 4597.
Das ist der letzte Eintrag (oder der erste) beim Absturz meiner fhem - sorry, ich bin nur Anwender, @Martin, sagt Dir das was und kannst Du mir weiter helfen? Absturz ist reproduzierbar mit diesem Eintrag!
Gruß
Ingo
P.S.: Reproduzierbar beim Versuch einen Dimmer auf einen (beliebigen) Prozentwert zu stellen. Den Dimmer mit up und down oder on off zu schalten führt nicht zum Absturz, auch einen Schalter ein- und auszuschalten funktioniert ohne Absturz.
Die Probleme in Zeile 4597 haben letztendlich alle die von Ansgar oben beschriebene Ursache, im gleichen Beitrag steht auch eine mögliche Lösung, die man temporär auch selbst in 10_CUL_HM.pm einbauen kann, bis martin das Problem "offiziell" löst und per update bereitstellt.
Alternativ verwendet man eben eine der vorherigen Modulversionen.
Index: 10_CUL_HM.pm
===================================================================
--- 10_CUL_HM.pm (revision 23069)
+++ 10_CUL_HM.pm (working copy)
@@ -4593,7 +4593,7 @@
if($param =~ m/^\((.*)\)$/ ){ # list of options?
my @parLst = split('\|',$1);
if( defined $parIn[$pCnt]){ # user param provided
- my ($tmp1) = map{my$foo=$_;;$foo =~ s/(.)/\\$1/g;;$foo}($parIn[$pCnt]);
+ my ($tmp1) = map{my$foo=$_;;$foo =~ s/([\\^.$|()[\]*+?{}\-#])/\\$1/g;;$foo}($parIn[$pCnt]);
if( $parIn[$pCnt] !~ m/[:\{\[\(]/ && grep/$tmp1/,@parLst){ # parameter not comparable or matched
}
elsif($param =~ m/([\-\d\.]*)\.\.([\-\d\.]*)/ ){# we check for min/max but not for step
Hallo Udo,
es sind zwei Stellen betroffen, siehe https://svn.fhem.de/trac/changeset/23058/ (https://svn.fhem.de/trac/changeset/23058/). Zeile 4596 und 5103.
Die zweite wird nur seltener zuschlagen, da regSet seltener zu Anwendung kommt. ;)
Gruß, Ansgar.
Aber aus der zweiten Stelle hatte ich bisher keine Probleme, deshalb habe ich die bisher noch nicht gepatcht. Ich hoffe ja, dass es kurzfristig eine reguläre Lösung gibt :)
Vielen Dank betateilchen!
Auch wenn ich mich jetzt leider als SuperDAU oute?
Wie geht das mit dem ändern oder verwenden einer alten Version? Das fängt schon damit an, dass ich mich frage wo ich es finde?
Sorry, ich bin (zwar begeisterter aber eben) nur Anwender, nachvollziehen und nachmachen klappt (auch mit putty), aber ohne die Profis wie Dich bin ich aufgeschmissen.
Danke und Gruß
Ingo
Na ja, via ssh einloggen (sollte mit einer aktuellen Win-Version auch ohne putty gehen), dann die betreffende Datei in einen Editor laden (ich empfehle gerne "mcedit" aus dem Paket "mc" => "sudo mcedit /opt/fhem/FHEM/10_CUL_HM.pm") und dann die betreffende Zeile ändern...
Oder eben die ganze Datei aus dem backup oder svn holen (https://svn.fhem.de/trac/export/22973/trunk/fhem/FHEM/10_CUL_HM.pm).
@martinp876:
Wäre es möglich, auch wieder die Möglichkeit zu reaktivieren, zwei Stellen hinter dem Komma als externen Temperatur-Wert zu verwenden?
2020.11.02 08:04:56 3: CUL_HM set Fake_Fenster_SZ_Temp virtTemp 22.44
2020.11.02 08:04:56 3: CUL_HM reject-set Fake_Fenster_SZ_Temp virtHum: param 0:'(off|0.0..99.0;0.1)' => not numeric
virtHum: (off|0.0..99.0;0.1)
Bei der letzten Version klappte das noch/wieder (sonst muß ich den Event-Handler umbauen, das Thema hatten wir neulich schon mal)....
oder einfach die alte Version vor dem Update wieder herstellen. Das geht mit dem Befehl restore, hier eine kurze Beschreibung:
ZitatPer default werden vor dem Überschreiben durch update alle Dateien in einem neuen Verzeichnis (restoreDir/update/YYYY-MM-DD) gesichert. Diese Dateien kann man einzeln oder komplett mit dem Befehl restore zurücksichern (z.Bsp.: restore update/2014-08-19 oder restore update/2014-08-19/fhem.pl) .
https://wiki.fhem.de/wiki/Update#R.C3.BCcksichern_beim_Update_.C3.BCberschriebener_Dateien
Mit dem Befehl restore list kannst Du Dir anschauen was Du hast.
Weckt Ihr mich bitte, wenn wir mal wieder einen halbwegs verlässlichen Funktionsstand bei CUL_HM haben? Ich traue mich seit Monaten kein Update mehr zu machen.
Bin deswegen auch in hm.js und Co temporär abgemeldet. Ich habe leider nicht den Luxus eines Testsystems...
Also was ich suche, ist eine funktionsfähige long-term-Lösung ohne Fehlerrisiko. Welcher Stand war das zuletzt? Kann ich mir ja im SVN ziehen...
fix eingecheckt
virtTemp möchte ich nicht auf 2 Nachkommastelle erweitern, da es a) unnötig ist und b) die OptionList endlos macht.
Man kann es bei Bedarf selbst ändern (wie alles in FHEM).
1) Kommando ändern:
{$HMConfig::culHmFunctSets{virtThSens}{virtTemp}="(off|-20.0..50.0;;0.01)"}
2) re-setup commands for device
{$defs{NAME}{helper}{cmds}{cmdKey}=""}
wobei "NAME" durch den Namen des/der Devices zu ersetzen ist. Also einmal für jede entity ausführen.
Kann man natürlich im UserConfig ausführen, was sonnvoller Weise nach dem System-Init stattfiden sollte.
Zitat von: martinp876 am 02 November 2020, 19:15:18
fix eingecheckt
getestet, scheint zu funktionieren.
Danke.
Hallo Martin,
hier noch eine grep Alternative, da Du vermutlich aus Perfomance Erwägungen den $foo match minimiert hast, was aber noch Crashpotential offen lässt (beispielsweise einzelne '(', ')' oder '[':
my ($tmp1) = map{my $foo=$_;$foo =~ s/([\?*+[()\\])/\\$1/g;$foo}($parIn[$pCnt]); # we need to consider special chars not to crash
if( $parIn[$pCnt] !~ m/[:\{\[\(]/ && grep/^\{?$tmp1\}?$/,@parLst){ # parameter not comparable or matched
}
und
return "$regName failed: supported register are ".join(" ",sort @regArr)
if (!grep $_ eq $regName,@regArr );
Das macht es sicherer auch für Typos bei der Eingabe.
Gruß, Ansgar.
Zitat von: martinp876 am 02 November 2020, 19:41:15
virtTemp möchte ich nicht auf 2 Nachkommastelle erweitern, da es a) unnötig ist und b) die OptionList endlos macht.
Na ja, es ging nicht um's Erweitern, es hatte ja funktioniert...
Aber egal, ich habe den Eventhandler jetzt angepaßt, ist einfacher als alles andere
Hallo Jörg,
Zitat2020.11.02 08:04:56 3: CUL_HM reject-set Fake_Fenster_SZ_Temp virtHum: param 0:'(off|0.0..99.0;0.1)' => not numeric
virtHum: (off|0.0..99.0;0.1)
was wird denn als virtHum gesetzt? Das steht ja nicht in Deinem Log. Ggf. mal das Logging ab Zeile 4637++ modifizieren/erweitern.
Gruß, Ansgar.
Edit: Sorry, ich war beim falschen Beta...
Bin zwar nicht Udo, aber das war mir gar nicht aufgefallen, dass das notify scheinbar dazu geführt hatte, dass auch noch ein virtueller Hum-Wert erzeugt wurde - sowas gab es im Log vorher und nachher nicht wieder, nur in der kurzen Zeit nach dem update und vor der Rückkehr zur Vorversion...
Das notify reagiert auch nur auf "temperature"-Events, von daher... k.A., was das war.
Letztlich ist es mir auch egal, ob ich jetzt vorher runden muss oder nicht, das Thema ist eher, dass "jemand" dann noch entsprechende Hinweise ins Wiki einbauen sollte...
Hallo Jörg,
Zeile 4601 10_CUL_HM.pm:
if ($parIn[$pCnt] !~ m/^[-+]?[0-9]+\.?[0-9]*$/){
$paraFail = "$parIn[$pCnt] not numeric";
}
matched auf beliebig viele Nachkommastellen! Das sollte Deinem Wunsch entsprechen.
Martin schrieb von der Anzahl Nachkommastellen bei der Auswahlliste (im Browser sichtbar) für set virtTemp. Und die auf 2 oder mehr aufzublasen kostet viel Speicher.
@Martin: Wie auch immer, hilfreich wäre, den Log Eintrag 4637++ um den "fehlerhaften" Parameterwert zu ergänzen.
Gruß, Ansgar.
Moin, irgendwie bin ich grade ständig auf dem Holzweg :( ...
Der setter in FHEMWEB ist in der Tat uninteressant, und lt. Log wurde ja auch die virtTemp korrekt weitergegeben. Zum Hintergrund: das notify reagiert auf einen Mix aus HUEDevice und MQTT2_DEVICE und sah ursprünglich so aus:
define n_Virtual_Temp_notify notify Temperatur_Schlafzimmer:temperature:.*|Raumfuehler_.*:temperature:.* set myRealTempSensor=$NAME virtTemp $EVTPART1
configdb search %virtHum% liefert keinen Treffer, allerdings ergab dann ein Blick ins Log vom Vormonat, dass da durchaus bereits schon schon entsprechende Einträge drin waren - aber (bezogen auf eines der Devices) nur in ca. 35 v. 1900 Fällen, und darunter sind auch Einträge, bei denen die Temp. einstellig war... (Und immer zusammen mit der betreffenden virtTemp-Anweisung, wobei das nur die MQTT2_DEVICE-Instanzen betrifft, da nur bei denen auch der Humidity-Wert mit im readingsBulkUpdate drin ist - die kommen von BT-Xiaomis über ein OpenMQTTGateway).
Schräger Zufall, dass das ausgerechnet "gepaßt hat", während ich gestern die paar Minuten im Log angesehen habe...
Für den Moment gehen mir die Ideen aus, und tendenziell ist es auch kein Thema für diesen Thread. Der ist [gelöst], oder?
Hallo zusammen,
ich bin neu hier im Forum, habe ein ähnliches Problem.
Ich denke das hängt zusammen, wollte euch aber die Info zukommen lassen, evtl. hilft das.
Bei mir stürzt FHEM ab, wenn ich für einen Homematic Dimmer einen Wert setze:
set Licht_Esstisch 50
set Licht_Esstisch 50 0 0
set Licht_Esstisch pct 50
Logfile:
2020.11.03 07:42:04 2: AttrTemplates: got 194 entries
Reference to nonexistent group in regex; marked by <-- HERE in m/\5 <-- HERE \0/ at /opt/fhem//FHEM/10_CUL_HM.pm line 4597.
Viele Grüße
Rob
Hab's eben mit der heutigen CUL_HM kurz angetestet: Das mit den pct klappt bei einem PBU-Dimmer ohne Absturz, ABER ohne Rückmeldung über die ausgeführte Schaltaktion, FHEM meint, das Ding wäre nicht erreichbar (Hauptkanal steht auf "MISSING ACK"). Kann grade nicht sagen, ob das ein spezielles Thema bei diesem Aktor ist, die beiden Rollladenaktoren direkt darunter funktionieren jedenfalls problemlos.
Zu dem anderen Thema noch: Kann es sein, dass das mit dem restart zusammenhängt und dann einfach die Daten aus der statefile missinterpretiert wurden? Das taucht nämlich bei näherer Betrachtung "im Pulk" auf - und nicht beschränkt auf "ungültige" Werte, wobei als "Anlass" nur ein Element gelistet ist. Hier mal ein auszugsweises log von einem Startvorgang im Oktober (den hatte ich halt grade zur Hand):
2020.10.03 08:46:49 3: Device Tuer_unten added to ActionDetector with 028:00 time
2020.10.03 08:46:49 3: CUL_HM set Fake_Fenster_Kind3_Temp virtTemp 22.6
2020.10.03 08:46:49 3: CUL_HM reject-set Fake_Fenster_Kind3_Temp virtHum: param 0:'(off|0.0..99.0;0.1)' => not numeric
virtHum: (off|0.0..99.0;0.1)
2020.10.03 08:46:49 3: CUL_HM reject-set Fake_Fenster_SZ_Temp virtTemp: param 0:'(off|-20.0..50.0;0.1)' => not numeric
virtTemp: (off|-20.0..50.0;0.1)
2020.10.03 08:46:49 3: CUL_HM reject-set Fake_Fenster_SZ_Temp virtHum: param 0:'(off|0.0..99.0;0.1)' => not numeric
virtHum: (off|0.0..99.0;0.1)
2020.10.03 08:46:49 3: CUL_HM reject-set Fake_Tuere_WZ_Temp virtTemp: param 0:'(off|-20.0..50.0;0.1)' => not numeric
virtTemp: (off|-20.0..50.0;0.1)
2020.10.03 08:46:49 3: CUL_HM reject-set Fake_Tuere_WZ_Temp virtHum: param 0:'(off|0.0..99.0;0.1)' => not numeric
virtHum: (off|0.0..99.0;0.1)
2020.10.03 08:46:55 3: FB_CALLMONITOR (Callmonitor) - found 1 phonebooks
Ja, Rolladenaktor (HM-LC-BL1PBU-FM) läuft bei mir auch ohne Probleme.
Mein Dimmer ist: HM-LC-DIM1TPBU-FM
Da stürzt FHEM ab.
Bei mir läuft es wieder nach dem update :D
DANKE!
Und auch danke für den Tipp mit dem restore (trotz bald 10 Jahren fhem war mir das neu - DAU halt), das hat mein System bis zum update wieder zum laufen gebracht.
Aber eigentlich ja ein gutes Zeichen, dass ich das restore in fast 10 Jahren noch nicht gebraucht hatte.
Jedenfalls vielen Dank an alle Profis, die mir so schnell und erfolgreich geholfen haben!
Gruß
Ingo
@Beta-User
ich habe nachgetestet - und kann es nicht nachstellen.
set vb_Btn9 virtTemp 1.444funktioniert.
set vb_Btn9 virtHum testzeigt Fehler. Soll auch.
Zitatparam 0:'(off|0.0..99.0;0.1)' => test not numeric
"test" wird ausgegeben
Zitat2020.10.03 08:46:49 3: CUL_HM reject-set Fake_Fenster_Kind3_Temp virtHum: param 0:'(off|0.0..99.0;0.1)' => not numeric virtHum: (off|0.0..99.0;0.1)
in deinem Fall wird der Parameter nicht ausgegeben. Seltsam - scheinbar wird "" an erster Stelle gesetzt. Sind da tabs im Kommando?
Ich habe es mit mehreren Leerzeichen probiert - fhem setzt die Liste korrekt...
hat sich da irgend ein whitespace reingemogelt?
Wie gesagt: Mir ist schon nicht klar, warum da überhaupt ein virtHum gesetzt wird - das scheint aus der CUL_HM-Initialisierung beim Start von FHEM zu kommen.
Es gibt afaik in meiner Installation keinen Event-handler, der diese Anweisung enthält - configdb search %virtHum% wirft jedenfalls nichts aus, und via myUtils mache ich da sehr sicher auch nichts.
Habe das noch nicht detailliert geprüft, aber tendenziell scheint das im laufenden Betrieb nicht vorzukommen.
Hallo Martin,
ZitatEs gibt afaik in meiner Installation keinen Event-handler, der diese Anweisung enthält - configdb search %virtHum% wirft jedenfalls nichts aus, und via myUtils mache ich da sehr sicher auch nichts.
ab Zeile 436 gibt es in CUL_HM noch in der Funktion CUL_HM_updateConfig($):
CUL_HM_Set($hash,$name,"valvePos",$d);
CUL_HM_Set($hash,$name,"virtTemp",ReadingsVal($name,"temperature",""));
CUL_HM_Set($hash,$name,"virtHum" ,ReadingsVal($name,"humidity",""));
ohne es untersucht zu haben, nur eine Idee, da ohne Reading ein set virtHum mit leerem Wert automatisch nach dem FHEM Start ausgelöst wird.
Gruß, Ansgar.
Hi Ansgar,
du hast natürlich recht. Ich hatte nicht verstanden, dass der Fehler "automatisch" kommt und nicht im Betrieb. Probleme sollte es keine gemacht haben, nur unschön.
Ist korrigiert.
Hallo Martin,
mit der Änderung laufen die Timer für meine virtuellen Temperatursensoren nicht mehr an.
Ich denke, das liegt an Zeile 426:
$hash->{helper}{virtTC} = "00";
Das verhindert, dass mit CUL_HM_Set($hash,$name,"virtTemp",$d) oder Setzen durch notifies in Zeile 6168
CUL_HM_valvePosUpdt("valvePos:$dst$chn");
aufgerufen wird, womit der Timer anlaufen soll.
{virtTC} dient als Flag in Zeile 6156, um mehrfachen Timerstart zu verhindern.
D.h. Zeile 426 müßte auch noch in den vdCtrl Block ab Zeile 434 umziehen, wenn ich das richtig sehe.
Gruß, Ansgar.
Zitat von: noansi am 08 November 2020, 20:27:01
Ich denke, das liegt an Zeile 426:
$hash->{helper}{virtTC} = "00";
Habe die Zeile mal testweise nach Zeile 443 (neu, also hinter 'elsif($hash->{helper}{fkt} eq "virtThSens"){') umgezogen. Das bringt leider keine Besserung.
Habe ich das falsch interpretiert oder gibt es andere Vorschläge, die man testen könnte?
Hallo Jörg,
für einen Virtuellen TH-Sensor darf es dort eben nicht ausgeführt werden.
Du musst es nach Zeile 434, also nach if ($hash->{helper}{fkt} eq "vdCtrl"){ umziehen, wie schon beschrieben.
Der vdCtrl benötigt es dagegen, weil er dort schon den Timer startet und der nicht durch sets nochmal gestartet werden darf.
Gruß, Ansgar.
OK, Danke für den Schubs, kann bestätigen: das Geblinke findet so ein Ende...
Wäre nett, wenn das dann auch den Weg ins svn fände, es warten wohl einige darauf, dass sie ihr FHEM wieder einem "gefahrlosen" Gesamtupdate unterziehen können.
Moin zusammen,
ich hatte das Phänomen, dass die Werte der RTs über den CUL über Nacht nicht mehr gesetzt wurden.
Sowohl das setzen einer Temp. am Device, als auch über Strukturen oder ein HM-TC-IT-WM-W-EU gingen ins leere.
Die Temp. an den Thermostaten blieb unverändert.
Folgendes ist dazu in der Log zu sehen:
2020.11.30 11:01:13.620 4: CUL_Parse: CUL0 A 0C B6 8470 314278 000000 00DD2408 -70
2020.11.30 11:01:13.622 5: CUL0: dispatch A0CB6847031427800000000DD24::-70:CUL0
2020.11.30 11:01:14.076 3: CUL_HM set kz_RT_Clima desired-temp 17.0
2020.11.30 11:01:16.067 5: CUL_HM set kz_RT_Clima ?
2020.11.30 11:01:16.072 5: CUL_HM set kz_RT_Clima ?
2020.11.30 11:01:16.073 5: CUL_HM get kz_RT_Clima ?
2020.11.30 11:01:19.641 5: CUL/RAW: /A0F63861021F6C30000000AA0DD0A004015
oder auch mit noch viel mehr Fragezeichen :-) :
2020.11.30 11:05:13.209 4: CUL_Parse: CUL0 A 0F B9 8002 24034C F11205 01041F003E401E -59
2020.11.30 11:05:13.210 5: CUL0: dispatch A0FB9800224034CF1120501041F003E40::-59:CUL0
2020.11.30 11:05:13.218 5: CUL0 sending As0CBAA011F1120524034C860421
2020.11.30 11:05:13.219 5: CUL 24034C dly:90ms
2020.11.30 11:05:13.310 5: SW: As0CBAA011F1120524034C860421
2020.11.30 11:05:18.797 4: CUL_HM_Resend: sz2_dg_RT nr 2
2020.11.30 11:05:23.451 5: CUL_HM set kz_RT_Clima ?
2020.11.30 11:05:23.458 5: CUL_HM set kz_RT_Clima ?
2020.11.30 11:05:23.460 5: CUL_HM get kz_RT_Clima ?
2020.11.30 11:05:33.843 3: CUL_HM set kz_RT_Clima desired-temp 18.0
2020.11.30 11:05:35.726 5: CUL_HM set kz_RT_Clima ?
2020.11.30 11:05:35.729 5: CUL_HM set kz_RT_Clima ?
2020.11.30 11:05:35.730 5: CUL_HM get kz_RT_Clima ?
2020.11.30 11:05:56.175 5: CUL/RAW: /A0F8086102200980000000A88AE0B054035
Nach einem Update, ich war aber relativ aktuell, werden die Temperaturen wieder gesetzt, die CUL Meldungen (mit Verboose 5) sehen aber nicht viel anders aus.
2020.11.30 12:05:16.020 4: CUL_Parse: CUL0 A 0F F2 8610 240359 000000 0A889A0C4C4028 -54
2020.11.30 12:05:16.021 5: CUL0: dispatch A0FF286102403590000000A889A0C4C40::-54:CUL0
2020.11.30 12:05:18.630 5: CUL_HM set kz_RT_Clima ?
2020.11.30 12:05:22.151 3: CUL_HM set kz_RT_Clima desired-temp 17.5
2020.11.30 12:05:25.801 5: CUL_HM set kz_RT_Clima ?
2020.11.30 12:05:31.584 5: CUL_HM set kz_RT_Clima ?
2020.11.30 12:05:31.587 5: CUL_HM set kz_RT_Clima ?
2020.11.30 12:05:31.588 5: CUL_HM get kz_RT_Clima ?
2020.11.30 12:05:37.612 5: CUL/RAW: /A0FCD861024034C0000000A84B410004023
get myCUL ccconf
CUL0 ccconf => freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
CUL0 raw => V 1.66 CUL868
Die Antenne habe ich nicht verstellt, keine Ahnung warum sich die Signalstärke geändert hat, kann ich nicht sagen, an dem vorsichtshalber durchgeführten Reboot vom Raspberry wird es nicht liegen.
Werden die "?" Sets (CUL_HM set kz_RT_Clima ?) auch gesendet, das würde den Traffic ja beträchtlich erhöhen oder sind das nur Logeinträge?
Gab es im CUL-Modul einen Fehler den ich mit dem Update behoben und im Forum nicht gefunden habe?
Hat jemand eine Idee woran dieses Verhalten liegt?
Grüße, bleibt gesund
Lars