Absturz durch Fehler in 10_CUL_HM.pm ?

martinp876 · 08 November 2020, 10:27:38

@Beta-User

ich habe nachgetestet - und kann es nicht nachstellen.

set vb_Btn9 virtTemp 1.444
funktioniert.

set vb_Btn9 virtHum test
zeigt 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?

Beta-User · 08 November 2020, 11:05:03

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.

noansi · 08 November 2020, 13:14:19

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($):

Code Auswählen

        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.

martinp876 · 08 November 2020, 17:37:58

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.

noansi · 08 November 2020, 20:27:01

Hallo Martin,

mit der Änderung laufen die Timer für meine virtuellen Temperatursensoren nicht mehr an.

Ich denke, das liegt an Zeile 426:

Code Auswählen

        $hash->{helper}{virtTC} = "00";

Das verhindert, dass mit CUL_HM_Set($hash,$name,"virtTemp",$d) oder Setzen durch notifies in Zeile 6168

Code Auswählen

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.

Beta-User · 23 November 2020, 10:30:59

Zitat von: noansi am 08 November 2020, 20:27:01
Ich denke, das liegt an Zeile 426:
Code Auswählen Erweitern
$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?

noansi · 23 November 2020, 19:01:06

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.

Beta-User · 24 November 2020, 07:33:15

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.

Lars_ · 30 November 2020, 12:46:03

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:

Code Auswählen


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

:

Code Auswählen

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.

Code Auswählen


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

Code Auswählen


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