HMCCU 5.0 im SVN verfügbar

[schic]

PS.: ein

Code: [Auswählen]

curl --data "dom.GetObject('BidCos-RF.MEQ1471146:1.LEVEL').State(-0.005);" http://MeineIP:8181/tclrega.exe

aus der Shell am selben Debian-Gerät, hat ebenfalls Erfolg. Das wäre mit einem entsprechenden Aufruf aus FHEM oder evtl. auch dem entsprechenden Perl-Pendant eine gangbare Ersatzlösung, aber leider ist die falsche Statusanzeige in FHEM damit noch nicht behoben.

[zap]

@schic Kannst Du bitte nochmal testen, was bei folgenden Befehlen passiert:

set HM_Sec_Win.SZ datapoint LEVEL -0.005

set HM_Sec_Win.SZ datapoint LEVEL -0.5

Wird bei einem der Befehle das Fenster verriegelt?

Leider meldet die CCU für den Datenpunkt LEVEL einen Minimalwert von 0.0. Negative Werte sind also eigentlich nicht zulässig.

[schic]

mit beiden Befehlen fährt das Fenster auf Null und verriegelt nicht weiter.

[schic]

den Datenpunkt LEVEL meldet eine Statusabfrage mit installiertem xml-api-Addon mit:

Code: [Auswählen]

http://192.168.xy.z/addons/xmlapi/state.cgi?device_id=1859&datapoint_id=1894
als Ergebnis:

Code: [Auswählen]

<state>

<datapoint ise_id="1894" value="-0.005000"/>
</state>

Ohne AddOn, mit dem "dom.GetObject" Gesums, habe ich das leider noch nicht auf die Reihe gebracht.

[zap]

Setz mal bitte für das Device ccuflags auf "trace". Dann führe den Befehl

set datapoint LEVEL -0.5

nochmal aus und schaue ins Logfile.

Da sollte sowas erscheinen:

Code: [Auswählen]

2022.08.16 13:05:07 2: HMCCUCHN: [RO_WZ_Terrasse : 3243406] [main::HMCCU_SetMultipleDatapoints] dpt=001.BidCos-RF.NEQ0513048:1.LEVEL, value=50
2022.08.16 13:05:07 2: HMCCUCHN: [RO_WZ_Terrasse : 3243406] [main::HMCCU_ScaleValue] chnno=1, dpt=LEVEL, value=50, mode=1
2022.08.16 13:05:07 2: HMCCUCHN: [RO_WZ_Terrasse : 3243406] [main::HMCCU_ScaleValue] Auto scaled value of LEVEL = 0.5

Dann setzt Du bitte ccuflags zusätzlich auf "noBoundsChecking" und wiederholst Befehl und Logauswertung.

[schic]

die m.E. relevante Log-Meldung:

Code: [Auswählen]

2022.08.16 14:04:14 2: HMCCUCHN: [HM_Sec_Win.SZ : 659] [main::HMCCU_ScaleValue] Auto scaled value of LEVEL = 0

differiert vom Soll "Auto scaled value of LEVEL = -0.005".
Die gesamte LOG-Meldung hängt an.

[schic]

PS.: die vermutlich 3 relevanten Zeilen:

Code: [Auswählen]


2022.08.16 14:04:14 2: HMCCUCHN: [HM_Sec_Win.SZ : 659] [main::HMCCU_SetMultipleDatapoints] dpt=001.BidCos-RF.MEQ1471146:1.LEVEL, value=-0.5
2022.08.16 14:04:14 2: HMCCUCHN: [HM_Sec_Win.SZ : 659] [main::HMCCU_ScaleValue] chnno=1, dpt=LEVEL, value=-0.5, mode=1
2022.08.16 14:04:14 2: HMCCUCHN: [HM_Sec_Win.SZ : 659] [main::HMCCU_ScaleValue] Auto scaled value of LEVEL = 0


[schic]

die Ausgabe von $min in 88_HMCCU.pm in dem Bereich nach # Auto scale (Zeile 9537) zeigt

Code: [Auswählen]

2022.08.16 14:49:11 2: HMCCUCHN: [HM_Sec_Win.SZ : 354364] [main::HMCCU_ScaleValue] min = 0.000000
und $mode wird mit 1 ausgegeben, so dass der relevante Bereich vermutl. aus Zeile 9554

Code: [Auswählen]

$value = $boundsChecking ? HMCCU_MinMax($value, $min*$f, $max*$f)/$f : $value/$f;hervorgeht.
(Zeile 9551:

Code: [Auswählen]

$value = HMCCU_MinMax ($value, $min, $max)*$f; evtl. auch).

$min scheint mit 0.000000 nicht passend zu sein. Um das aber weiter zu verfolgen, fürchte ich, reicht meine Perl-Praxis kein Bisschen.

[roman1528]

Moin.

Habe seit ein paar Tagen eine CCU3 und stelle Raumweise darauf um. Mittlerweile hab ich auf der CCU RaspberryMatic am laufen.

Habe leider arge Probleme beim setzen des CONTROL_MODE bei HM-TC-IT-WM-W-EU (HM-Wandthermostat) bzw. HM-CC-RT-DN (HM-Heizkörperthermostat).

Code: [Auswählen]

set <DEVICE> auto
set <DEVICE> manu
set <DEVICE> boostDer Befehl kommt in der CCU an und wird an's Thermostat weitergegeben.
Die Rückmeldung von der CCU an FHEM kommt auch an...

Allerdings hängt FHEM sich kurz weg (Connection lost....), sodass kein Event erzeugt wird. Wichtig für z.B. Statusanzeige bzw. optische Änderungsbestätigung in FTUI.

Wo ich definitiv auch nicht durchblicke sind diese ganzen Attribute im CCU IO und in den RPC's. Ich habe am CCU IO folgende ccuflags gesetzt. gibt es da noch mehr zu beachten? Mehr Doku? Auf Deutsch?

Code: [Auswählen]

ccuflags
procrpc,nonBlocking,reconnect
Und noch 'ne Frage....
Warum kann ich die RPC's nicht umbenennen? (werden nach Neustart mit anderem Namen neu erstellt).

Vielen Dank schon mal.

Grüße^^

Ohne Witz... Ich schmeiß diese blöde Technik gleich komplett raus...

Ich bekomme jetzt bei Änderungen gar keine Events mehr Egal wo die Änderung stattfindet... Und ja ich habe artig die Reihenfolgen befolgt.

CCU neustart -> RPC neustart -> get "IO" ccuConfig ... und immer schön warten...

Wenn ein Gerät z.B. seinen aktuellen Status (cyclic) mitteilt ist alles schön. Aber sofern es eine Änderung gibt bekomme ich keine Events in FHEM und FHEM bleibt kurz stehen bzw. schmeißt auf jeden Fall den Websocket.

[frank]

Aber sofern es eine Änderung gibt bekomme ich keine Events in FHEM

wie checkst du das?
gibt es im event log einen eintrag?

[roman1528]

wie checkst du das?
gibt es im event log einen eintrag?

indem mir FHEMWEB anzeigt "Connection lost..." und in FTUI keine Änderungen angezeigt werden... und FHEMApp sich neu verbindet...

okay... userReadings werden aktualisiert...

das Frontend ist doch aber wichtig um eine visuelle Bestätigung der Eingabe zu bekommen.

[zap]

die Ausgabe von $min in 88_HMCCU.pm in dem Bereich nach # Auto scale (Zeile 9537) zeigt

Code: [Auswählen]

2022.08.16 14:49:11 2: HMCCUCHN: [HM_Sec_Win.SZ : 354364] [main::HMCCU_ScaleValue] min = 0.000000
und $mode wird mit 1 ausgegeben, so dass der relevante Bereich vermutl. aus Zeile 9554

Code: [Auswählen]

$value = $boundsChecking ? HMCCU_MinMax($value, $min*$f, $max*$f)/$f : $value/$f;hervorgeht.
(Zeile 9551:

Code: [Auswählen]

$value = HMCCU_MinMax ($value, $min, $max)*$f; evtl. auch).

$min scheint mit 0.000000 nicht passend zu sein. Um das aber weiter zu verfolgen, fürchte ich, reicht meine Perl-Praxis kein Bisschen.

Gleiches Ergebnis wenn Du ccuflags auf noBoundsChecking setzt?

Die richtige Stelle im Code hast Du gefunden. Ich habe "noBoundsChecking" genau für den Fall eingebaut, dass in der CCU für einen Datenpunkt die falschen Grenzwerte definiert sind. Das min=0 kommt von der CCU, nicht von HMCCU.

[schic]

 

Gleiches Ergebnis wenn Du ccuflags auf noBoundsChecking setzt?

habe gesetzt und mit dem Befehl

Code: [Auswählen]

datapoint LEVEL -0.5verriegelt das Fenster. Aber der Status bzw LEVEL-Reading geht nur auf "closed".

Mit "Lock-Icon" anklicken geht das auf "closed" ohne Verriegelung.

[zap]

Das ist ja schonmal die halbe Miete. Die richtige Konvertierung zurück in den Status schaue ich mir an.

Was steht eigentlich im Reading pct, wenn das Fenster verriegelt ist?

[zap]

@roman1528 einziger Unterschied scheint FTUI zu sein.