HMCCU 5.0 im SVN verfügbar

Begonnen von zap, 26 Oktober 2021, 19:01:00

Vorheriges Thema - Nächstes Thema

schic

PS.: ein
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.
Debian Bullseye x86_64 headless
parallell laufende Serversoftware:
AdGuard Home, LMS + MusicIP, baical carddav, Debmatic mit HmIP-RFUSB, zigbee2mqtt mit Mosquitto,
FHEM mit den Grundmodulen: HMCCU, Velux Gateway KLF200, TCM mit USB 300, HUEBridge, harmony, SB_SERVER, LGTV_WebOS, PIONEERAVR

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.
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

schic

mit beiden Befehlen fährt das Fenster auf Null und verriegelt nicht weiter.
Debian Bullseye x86_64 headless
parallell laufende Serversoftware:
AdGuard Home, LMS + MusicIP, baical carddav, Debmatic mit HmIP-RFUSB, zigbee2mqtt mit Mosquitto,
FHEM mit den Grundmodulen: HMCCU, Velux Gateway KLF200, TCM mit USB 300, HUEBridge, harmony, SB_SERVER, LGTV_WebOS, PIONEERAVR

schic

den Datenpunkt LEVEL meldet eine Statusabfrage mit installiertem xml-api-Addon mit:
http://192.168.xy.z/addons/xmlapi/state.cgi?device_id=1859&datapoint_id=1894

als Ergebnis:<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.
Debian Bullseye x86_64 headless
parallell laufende Serversoftware:
AdGuard Home, LMS + MusicIP, baical carddav, Debmatic mit HmIP-RFUSB, zigbee2mqtt mit Mosquitto,
FHEM mit den Grundmodulen: HMCCU, Velux Gateway KLF200, TCM mit USB 300, HUEBridge, harmony, SB_SERVER, LGTV_WebOS, PIONEERAVR

zap

#499
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:


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.
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

schic

#500
die m.E. relevante Log-Meldung:
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.


Debian Bullseye x86_64 headless
parallell laufende Serversoftware:
AdGuard Home, LMS + MusicIP, baical carddav, Debmatic mit HmIP-RFUSB, zigbee2mqtt mit Mosquitto,
FHEM mit den Grundmodulen: HMCCU, Velux Gateway KLF200, TCM mit USB 300, HUEBridge, harmony, SB_SERVER, LGTV_WebOS, PIONEERAVR

schic

PS.: die vermutlich 3 relevanten Zeilen:


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
Debian Bullseye x86_64 headless
parallell laufende Serversoftware:
AdGuard Home, LMS + MusicIP, baical carddav, Debmatic mit HmIP-RFUSB, zigbee2mqtt mit Mosquitto,
FHEM mit den Grundmodulen: HMCCU, Velux Gateway KLF200, TCM mit USB 300, HUEBridge, harmony, SB_SERVER, LGTV_WebOS, PIONEERAVR

schic

#502
die Ausgabe von $min in 88_HMCCU.pm in dem Bereich nach # Auto scale (Zeile 9537) zeigt
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
$value = $boundsChecking ? HMCCU_MinMax($value, $min*$f, $max*$f)/$f : $value/$f;
hervorgeht.
(Zeile 9551: $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.
Debian Bullseye x86_64 headless
parallell laufende Serversoftware:
AdGuard Home, LMS + MusicIP, baical carddav, Debmatic mit HmIP-RFUSB, zigbee2mqtt mit Mosquitto,
FHEM mit den Grundmodulen: HMCCU, Velux Gateway KLF200, TCM mit USB 300, HUEBridge, harmony, SB_SERVER, LGTV_WebOS, PIONEERAVR

roman1528

Zitat von: roman1528 am 14 August 2022, 12:06:59
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).
set <DEVICE> auto
set <DEVICE> manu
set <DEVICE> boost

Der 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?
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.
i3-10305T 4x3GHz;8GB RAM;250GB & 1TB NVMe:
FHEM 6.2;FTUI;8" Tablet's+Fully;NsPanelPro;HUE;ESPRGBWW;HM(CCU3);Duofern; ASC;MQTT(Tasmota);netatmo;SONOS;eBus;DbLog;XiaomiDevice;NUT;ModbusAttr

RPi3+: FHEM 6.2;I²C;GPIO;RFID;G-Tag;XiaomiBTLESens
RPi3: FHEM 6.2;DIY Relais-Board;I²C;GPIO;RFID;Photovoltaik

frank

ZitatAber sofern es eine Änderung gibt bekomme ich keine Events in FHEM
wie checkst du das?
gibt es im event log einen eintrag?
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

roman1528

Zitat von: frank am 16 August 2022, 15:29:24
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.
i3-10305T 4x3GHz;8GB RAM;250GB & 1TB NVMe:
FHEM 6.2;FTUI;8" Tablet's+Fully;NsPanelPro;HUE;ESPRGBWW;HM(CCU3);Duofern; ASC;MQTT(Tasmota);netatmo;SONOS;eBus;DbLog;XiaomiDevice;NUT;ModbusAttr

RPi3+: FHEM 6.2;I²C;GPIO;RFID;G-Tag;XiaomiBTLESens
RPi3: FHEM 6.2;DIY Relais-Board;I²C;GPIO;RFID;Photovoltaik

zap

#506
Zitat von: schic am 16 August 2022, 15:03:31
die Ausgabe von $min in 88_HMCCU.pm in dem Bereich nach # Auto scale (Zeile 9537) zeigt
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
$value = $boundsChecking ? HMCCU_MinMax($value, $min*$f, $max*$f)/$f : $value/$f;
hervorgeht.
(Zeile 9551: $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.
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

schic

 
ZitatGleiches Ergebnis wenn Du ccuflags auf noBoundsChecking setzt?
habe gesetzt und mit dem Befehl datapoint LEVEL -0.5
verriegelt das Fenster. Aber der Status bzw LEVEL-Reading geht nur auf "closed".

Mit "Lock-Icon" anklicken geht das auf "closed" ohne Verriegelung.
Debian Bullseye x86_64 headless
parallell laufende Serversoftware:
AdGuard Home, LMS + MusicIP, baical carddav, Debmatic mit HmIP-RFUSB, zigbee2mqtt mit Mosquitto,
FHEM mit den Grundmodulen: HMCCU, Velux Gateway KLF200, TCM mit USB 300, HUEBridge, harmony, SB_SERVER, LGTV_WebOS, PIONEERAVR

zap

#508
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?
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

zap

@roman1528 einziger Unterschied scheint FTUI zu sein.
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB