virtuelle "HmIP-Heizgruppengeräte" nicht einstellbar mit Nightly 3.77.2.xxx

[Baxxy13]

Describe the issue you are experiencing

Mit aktuellem Nightly 3.77.2.xxx können die virtuellen HmIP-Heizgruppengeräte nicht mehr "eingestellt" werden. Es ist egal ob man über... > Einstellungen > Gruppen -> "HmIP-Heizgruppengerät" -> "Einstellen" oder über... > Einstellungen > Geräte -> "HmIP-Heizgruppengerät" -> "Einstellen" ... reingeht, es erscheint immer nur "keine Parameter einstellbar".

Describe the behavior you expected

Einstellungen der HmIP-Heizgruppengeräte sollten wie gehabt erscheinen und einstellbar sein.

Steps to reproduce the issue

1. aktuellen Nightly installieren
2. HmIP-Heizgruppe anlegen
3. HmIP-Heizgruppe "Einstellen" ...

What is the version this bug report is based on?

3.77.2.20240613 - Nightly

Which base platform are you running?

lxc_arm64 (Linux Container Infrastructure, ARM64/aarch64)

Which HomeMatic/homematicIP radio module are you using?

RPI-RF-MOD

Anything in the logs that might be useful for us?

- keine Auffälligkeiten im syslog
- keine Auffälligkeiten in der Browserkonsole

Additional information

Grundsätzlich erzeuge ich immer erst eine "leere" HmIP-Heizgruppe in der ich dann die Grundeinstellungen (Wochenprogramme, Fenster-Auf-Temperatur, etc.) vornehme. Erst danach füge ich Geräte hinzu. Das funktionierte bisher immer, und es funktioniert auch mit der letzten offiziellen RaspberryMatic 3.75.7.20240601.

3.77.2.20240613 - Nightly

3.75.7.20240601 - latest Stable

[Baxxy13]

eQ-3 ist ganz sicher schon schwer mit dem "Fixen" beschäftigt... 😉

Trotzdem ein kleines Update:

Return-Path: <CGI script - do not reply>
From:  <CGI script - do not reply>
To: root
Subject:  CGI problem

CGI environment:
REQUEST_METHOD: POST
SCRIPT_NAME: /config/ic_deviceparameters.cgi
HTTP_USER_AGENT: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36
HTTP_HOST: 192.168.1.191
REMOTE_ADDR: 192.168.1.3
cgi.tcl version: 1.10.0
input:
iface=VirtualDevices&address=INT0000001&redirect_url=GO_BACK&_=
cookie:
JSESSIONID=node01c67jmw3utp621htry025okhlf1.node0
errorInfo:
can't read "ps(EFFECT_ADAPTION_FADE_OUT_TIME_FACTOR)": no such element in array
    while executing
"append html "<td><input id='separate_$channel\_$prn' name='$param\_FACTOR' class='j_effectFactor\_$prn' type='text' value=$ps($param\_FACTOR)></td>""
    (procedure "getSelectBoxTime" line 42)
    invoked from within
"getSelectBoxTime $CHANNEL EFFECT_ADAPTION_FADE_OUT_TIME colorFadeTime $prn"
    (procedure "getHeatingControlEffects" line 20)
    invoked from within
"getHeatingControlEffects $chn"
    (procedure "getHeatingClimateControlTransceiver" line 365)
    invoked from within
"getHeatingClimateControlTransceiver $chn ps psDescr $address"
    (procedure "set_htmlParams" line 13)
    invoked from within
"set_htmlParams $iface $ch_address ch_ps ch_ps_descr CHANNEL_$ch_descr(INDEX) """
    (procedure "put_channel_parameters" line 129)
    invoked from within
"put_channel_parameters"
    (procedure "put_page" line 133)
    invoked from within
"put_page"

[github-actions[bot]]

@Baxxy13, the issue you reported cannot be solved within this project or should be better directly solved in the upstream OCCU project RaspberryMatic is just using. However, for being able to reference and track this upstream issue we will keep this ticket open for the time being so that you can also reference it accordingly.

[jp112sdl]

Es werden zunächst 3 Bedingungen "ODER"-geprüft: /www/config/easymodes/etc/hmipChannelConfigDialogs.tcl#L3017

if { ([info exists ps(CHANNEL_OPERATION_MODE)] == 1) || ([info exists ps(ACOUSTIC_ALARM_SIGNAL)] == 1) || ([info exists ps(EFFECT_ADAPTION_FADE_OUT_TIME_FACTOR)] == 1)  } {

Zum Schluss wird in /www/config/easymodes/etc/hmipChannelConfigDialogs.tcl#L3055

append html "[getHeatingControlEffects $chn]"

aufgerufen, ohne vorher nochmals zu prüfen, ob denn explizit der Parameter EFFECT_ADAPTION_FADE_OUT_TIME_FACTOR exitsiert.

Es hätte hier noch mal eine Prüfung stattfinden müssen, wie in /www/config/easymodes/etc/hmipChannelConfigDialogs.tcl#L3042-L3043

set param EFFECT_ADAPTION_FADE_OUT_TIME_FACTOR
if { [info exists ps($param)] == 1  } {

Ansonsten wird halt in getHeatingControlEffects eingestiegen, wenn auch nur CHANNEL_OPERATION_MODE existiert.

[Baxxy13]

Da hast du ja wieder tief gegraben. 😉 Das fixing sollte aber eQ-3 übernehmen denn wenn wir da jetzt selbst Hand anlegen kommen die eh demnächst mit der gefixten Version um die Ecke. Hatten wir ja in letzter Zeit mehrfach.

Mir ging's primär darum darauf hinzuweisen das in der 3.77.2 - Version ein unschöner Fehler steckt.

[jens-maus]

Da hast du ja wieder tief gegraben. 😉 Das fixing sollte aber eQ-3 übernehmen denn wenn wir da jetzt selbst Hand anlegen kommen die eh demnächst mit der gefixten Version um die Ecke. Hatten wir ja in letzter Zeit mehrfach.

In der Tat hat meinen Infos nach eQ3 das problem bereits gefixt und ein OCCU Update ist quasi in Arbeit... Schauen wir dann mal was da so um die Ecke kommt ...

[jens-maus]

So, der nächste nightly snapshot sollte auf OCCU 3.77.4 basieren welches anscheinend das Problem hier beheben sollte. Bitte morgen entsprechend testen und dann berichten damit wir hier ggf. dicht machen können :-)

[Baxxy13]

Können wir schließen. eQ-3 hat's mit 3.77.4 gefixt.