HMCCU 5.0 im SVN verfügbar

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

Vorheriges Thema - Nächstes Thema

schwatter

Zitat von: zap am 27 Oktober 2021, 19:55:30
@schwatter: der FALMOT hat eine Kanalrolle, die bisher von get create nicht erkannt wird.

Die manuelle Definition mit HMCCUDEV oder HMCCUCHN muss jedoch funktionieren und auch die Readings müssen aktualisiert werden.

Ok,
habe nochmal den Falmot gelöscht. Angelegt hatte ich ihn aus meinen alten Save.

define HmIP_FALMOT_C12 HMCCUDEV 001B9BE98FF62A

Da wurden auch alle Readings aktualisiert. Habe ihn jetzt trotzdem nochmal gelöscht und neu angelegt mit

define HmIP_FALMOT_C12 HMCCUDEV 001B9BE98FF62A forceDev

Und statedatapoint habe ich auch hinzugefügt. Sollte passen.

Danke!

Gruß schwatter

tndx

Zitat von: zap am 27 Oktober 2021, 20:28:01
Du könntest "set defaults reset" ausführen. Das löscht einige Attribute. Wenn jedoch das Device nur über einen Kanal angesprochen wird und du es als HMCCUDEV angelegt hast, dürfte eine Neudefinition mit "get createDev" der bessere Weg sein. In dem Fall kannst Du es auch einfach ausprobieren und hast dann eben erst mal 2 Devices

"set defaults reset" habe ich, wie in einem der früheren Postings geschrieben, bereits ausgeführt. Trotzdem bin ich mir fast sicher, dass zumindest die Attribute
attr GWC_Pres eventMap /datapoint 1.RESET_PRESENCE 1:reset/datapoint 1.PRESENCE_DETECTION_ACTIVE 1:detection-on/datapoint 1.PRESENCE_DETECTION_ACTIVE 0:detection-off/
attr GWC_Pres hmstatevals SABOTAGE!(1|true):sabotage
attr GWC_Pres statedatapoint 1.PRESENCE_DETECTION_STATE
attr GWC_Pres substitute PRESENCE_DETECTION_STATE!(0|false):no,(1|true):yes;;PRESENCE_DETECTION_ACTIVE!(0|false):off,(1|true):on


von der Vorgänger-Version stammen. Zumal es die Datapoints "1.RESET_PRESENCE", "1.PRESENCE_DETECTION_ACTIVE", "1.PRESENCE_DETECTION_ACTIVE" und "SABOTAGE" aktuell gar nicht zu geben scheint, zumindest mit der aktuellen Konfiguration.

Da es aktuell zu funktionieren scheint, würde ich im Zweifelsfall lieber alles so belassen, als anfangen mit Neuanlegen und 2 Devices zu experimentieren, wenn es nicht unbedingt sein soll.

alkazaa

Zitat von: zap am 26 Oktober 2021, 19:01:00
Ich habe gerade HMCCU 5.0 ins SVN eingecheckt. Das Update steht morgen per FHEM Update zur Verfügung.

Guten Morgen zap!

Ich wurde zwar gestern bei der Bastelei auf einer anderen FHEM Baustelle nach einem update etwas überrascht vom unerwarteten neuen HMCCU, habe die kleinen Änderungen mit Hilfe des Wiki Artikels aber schnell in den Griff gekriegt.

Allerdings habe ich jetzt noch ein kleines Problem bei einem device, das einen BLIND_TRANSMITTER "HmIP-BBL" steuert. Der hat nicht nur das reading/setting 'pct' für die Höhe des Raffstores, sondern auch einen Lamellenwinkel. Den Winkel kann ich zwar mit "set datapoint 4.LEVEL_2 50 4.LEVEL 100.5" (auf in diesem Beispiel 50%) steuern, aber eine einfaches "set winkel 50" wäre deutlich einfacher (u.a. für eine Anbindung an smartvisu).

Bei der alten HMCCU Version hatte ich das mit eventmap nachgebildet. Auch ein "set winkel_hoehe w h" hatte ich realisiert, mit dem Winkel und Höhe des Raffstores mit einem Befehl auf die Werte w und h gestellt wurden.

Kann man sowas in HMCCU 5.0 auch hinkriegen?

Vielen Dank,
und beste Grüße
Franz

zap

Zitat von: tndx am 27 Oktober 2021, 21:49:50
"set defaults reset" habe ich, wie in einem der früheren Postings geschrieben, bereits ausgeführt. Trotzdem bin ich mir fast sicher, dass zumindest die Attribute
attr GWC_Pres eventMap /datapoint 1.RESET_PRESENCE 1:reset/datapoint 1.PRESENCE_DETECTION_ACTIVE 1:detection-on/datapoint 1.PRESENCE_DETECTION_ACTIVE 0:detection-off/
attr GWC_Pres hmstatevals SABOTAGE!(1|true):sabotage
attr GWC_Pres statedatapoint 1.PRESENCE_DETECTION_STATE
attr GWC_Pres substitute PRESENCE_DETECTION_STATE!(0|false):no,(1|true):yes;;PRESENCE_DETECTION_ACTIVE!(0|false):off,(1|true):on


von der Vorgänger-Version stammen. Zumal es die Datapoints "1.RESET_PRESENCE", "1.PRESENCE_DETECTION_ACTIVE", "1.PRESENCE_DETECTION_ACTIVE" und "SABOTAGE" aktuell gar nicht zu geben scheint, zumindest mit der aktuellen Konfiguration.

Da es aktuell zu funktionieren scheint, würde ich im Zweifelsfall lieber alles so belassen, als anfangen mit Neuanlegen und 2 Devices zu experimentieren, wenn es nicht unbedingt sein soll.

Das "set defaults reset" funktioniert (vermutlich) nicht bei einem HMCCUDEV Device, wenn HMCCU der Meinung ist, dass ein HMCCUCHN die bessere Wahl wäre. Andernfalls müsste ich das alte Device automatisch löschen und ein neues anlegen. Da wäre der eine oder andere Nutzer mit Recht verärgert gewesen.
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

Zitat von: alkazaa am 28 Oktober 2021, 08:14:19
Guten Morgen zap!

Ich wurde zwar gestern bei der Bastelei auf einer anderen FHEM Baustelle nach einem update etwas überrascht vom unerwarteten neuen HMCCU, habe die kleinen Änderungen mit Hilfe des Wiki Artikels aber schnell in den Griff gekriegt.

Allerdings habe ich jetzt noch ein kleines Problem bei einem device, das einen BLIND_TRANSMITTER "HmIP-BBL" steuert. Der hat nicht nur das reading/setting 'pct' für die Höhe des Raffstores, sondern auch einen Lamellenwinkel. Den Winkel kann ich zwar mit "set datapoint 4.LEVEL_2 50 4.LEVEL 100.5" (auf in diesem Beispiel 50%) steuern, aber eine einfaches "set winkel 50" wäre deutlich einfacher (u.a. für eine Anbindung an smartvisu).

Bei der alten HMCCU Version hatte ich das mit eventmap nachgebildet. Auch ein "set winkel_hoehe w h" hatte ich realisiert, mit dem Winkel und Höhe des Raffstores mit einem Befehl auf die Werte w und h gestellt wurden.

Kann man sowas in HMCCU 5.0 auch hinkriegen?

Vielen Dank,
und beste Grüße
Franz

Das Attribut eventMap ist ja nicht verboten. Es wird halt wieder gelöscht, wenn Du einen Reset der Defaults machst. Ich schau mal, ob ich einen entsprechenden Befehl vordefinieren kann. Bis dahin kannst Du Dir mit eventMap behelfen.

Wahrscheinlich werde ich auch das Löschen von eventMap wieder ausbauen und den Nutzer beim Reset nur darauf hinweisen, dass dieses Attribut angepasst oder gelöscht werden sollte.
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

alkazaa

Zitat von: zap am 28 Oktober 2021, 09:44:25
Das Attribut eventMap ist ja nicht verboten.

Ok, und danke für die schnelle Antwort. Da hatte ich das mit evenMap irgendwie missverstanden.
Damit kann ich dann ja wieder die alte Funktionalität herstellen.

(Und für die HMIP-BBL Nutzer, die vielleicht suchmaschinenmäßig auf diesen Beitrag stoßen: Es ist in der Tat so, dass nur  "set datapoint 4.LEVEL_2 50 4.LEVEL 100.5" den Lamellenwinkel verändert, ein  "set datapoint 4.LEVEL_2 50" allein tut's anscheinend nicht. Der Wert 100.5 für 4.Level bedeutet übrigens 'letzter Wert', 101 würde bedeuten 'Ignorieren', und Werte 0...100 wären anzufahrende Behanghöhen)

-Franz

zap

Wäre dann nicht 101 der richtige Wert, wenn man nur den Winkel verstellen möchte? Sonst wird ja auch das LEVEL auf den alten Wert gesetzt
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

alkazaa

#22
Ich hatte die Zuordnung von '100.5'=>'letzter Wert' und '101'=>'Ignorieren' aus dem Homematic GUI erschlossen.

Ehrlich gesagt verstehe ich den Unterschied zwischen 'letzter Wert' und 'Ignorieren' aber nicht wirklich, und ich habs daher mal ausprobiert:

Ausgangspunkt: Höhe und Winkel bei 50 %
"set <device> datapoint 4.LEVEL_2 25 4.LEVEL 100.5" fährt Winkel auf 25, Höhe bleibt
"set <device> datapoint 4.LEVEL_2 25 4.LEVEL 101" fährt Winkel auf 25, Höhe auf 0  (!)
"set <device> datapoint 4.LEVEL_2 25 4.LEVEL 18" fährt Winkel auf 25, Höhe auf 18

Gibt man die 101, bzw. 100.5 als Parameter von 4.LEVEL_2 an, ist es ähnlich: bei 100.5 bleibt der Winkel wie er war, bei 101 geht er auf 0. Aber den 4.LEVEL kann man ja setzen, ohne 4.LEVEL_2 zu erwähnen ("set <device> datapoint 4.LEVEL nn"), während für 4.LEVEL_2 anscheinend auch immer 4.LEVEL (als zweiter! Parameter) mit gesetzt werden muss. Jedenfalls funktioniert es bei mir nur so.

tomcat.x

Nach dem Update hatte ich ein paar Fehler mit unbekannten Attributen beim HMCCU Device. Habe dann geschaut, was da vorher gesetzt war, dann ohne die Attribute gespeichert und neu gestartet. Für ein Attribut bekomme ich den Fehler damit aber nicht weg: "unknown attribute rpcinterfaces". Das wird doch aber noch gebraucht und gibt es daher auch noch. Ich habe dann neu auf "HmIP-RF" gesetzt, gespeichert und neu gestartet. Leider ohne Erfolg. Momentan muss ich also nach dem Start erst das Attribut setzen und dann manuell den RPC-Server starten.

Dabei habe ich über folgendes gestolpert: Wenn ich im Gerät bei"Set" erst "rpcserver" und dann "on" auswähle, bekomme ich als Fehler "HMCCU: <MeinGerätename> Usage: set <MeinGerätename> [rpcserver] {'on'|'off'} " angezeigt, also genau die gewählte Syntax. Auch manuell eingegeben funktioniert das nicht, nur ohne das optionale "rpcserver".
FHEM: 6.1 auf Raspi 3, Raspbian (Buster), Perl v5.28.1
Sender/Empfänger: 2 x CULv3, Duofern Stick, HM-MOD-RPI-PCB
Gateways: FRITZ!Box 6591 (OS: 7.57), Trädfri, ConBee 2,  piVCCU, OpenMQTTGateway
Sensoren/Aktoren: FRITZ!DECT, FS20, FHT, HMS, HomeMatic, Trädfri, DuoFern, NetAtmo

tndx

Zitat von: zap am 28 Oktober 2021, 09:32:58
Das "set defaults reset" funktioniert (vermutlich) nicht bei einem HMCCUDEV Device, wenn HMCCU der Meinung ist, dass ein HMCCUCHN die bessere Wahl wäre. Andernfalls müsste ich das alte Device automatisch löschen und ein neues anlegen. Da wäre der eine oder andere Nutzer mit Recht verärgert gewesen.

OK, danke, das Argument verstehe ich natürlich! Aber nach welchen Kriterien entscheidet HMCCU ob HMCCUDEV oder HMCCUCHN die bessere Wahl ist? Klar, habe deine Beispiele gesehen im 1. Post, aber wann gibt es dann noch nach HMMCCU-Einschätzung HMCCUDEV? Oder ist es nur noch ein Relikt?


zap

Ich werde das Beispiel mal noch etwas erweitern. Aber allgemein verhält es sich so: sobald ein Gerät mehrere unterschiedliche Rollen hat (also Kanäle mit unterschiedlichen Rollen) und mindestens 2 dieser Kanäle für die Integration benötigt werden, wird HMCCUDEV verwendet, weil nur dieses Modul mehrere Kanäle unterstützt.
Beispiel: Ein Wand-Thermostat hat einen Kanal zur Temperaturregelung und einen weiteren Kanal, über den der Zustand eines Fensters angezeigt wird (sofern verknüpft).


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

Es gibt ein Update: Bei Ausführung von "set defaults reset" wird das Attribut eventMap nicht mehr gelöscht. Stattdessen wird ein Hinweis angezeigt, dass eventuelle HMCCU 4.3 Einträge in diesem Attribut entfernt werden müssen.
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

Frage an diejenigen, bei denen beim Start von FHEM das Attribut "room" gelöscht wurde: Habe Ihr im Define vom I/O Device ein ccudelay angegeben?
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

Ralli

#28
Hallo zap,

mit der aktuellen Version habe ich übrigens immer noch das gleiche alte Thema:


...
2021.10.29 09:07:04.744 1: HMCCU [CCU2] All RPC servers running
2021.10.29 09:07:04.755 2: HMCCU [CCU2] Updating 123 of 123 client devices matching devexp=.* filter=ccudevstate=active,ccuif=BidCos-Wired|HmIP-RF|BidCos-RF
2021.10.29 09:07:04.759 1: HMCCURPCPROC [d_rpcBidCos_RF] Scheduled CCU ping every 300 seconds
2021.10.29 09:07:04.767 2: HMCCURPCPROC [d_rpcHmIP_RF] CB2010000029000020 NewDevice received 123 device and channel specifications
2021.10.29 09:07:04.840 2: HMCCURPCPROC [d_rpcBidCos_RF] CB2001000029000020 NewDevice received 430 device and channel specifications
2021.10.29 09:27:11.862 1: HMCCU [CCU2] Graceful shutdown in 8 seconds
...
2021.10.29 09:27:55.633 1: HMCCU [CCU2] All RPC servers running
2021.10.29 09:27:55.640 2: HMCCU [CCU2] Updating 123 of 123 client devices matching devexp=.* filter=ccudevstate=active,ccuif=HmIP-RF|BidCos-RF|BidCos-Wired
2021.10.29 09:27:55.651 1: HMCCURPCPROC [d_rpcBidCos_RF] Scheduled CCU ping every 300 seconds
2021.10.29 09:27:55.698 2: HMCCURPCPROC [d_rpcHmIP_RF] CB2010000029000020 NewDevice received 123 device and channel specifications
2021.10.29 09:27:55.731 2: HMCCURPCPROC [d_rpcBidCos_RF] CB2001000029000020 NewDevice received 430 device and channel specifications
2021.10.29 09:27:56.273 2: HMCCU [CCU2] Update success=123 failed=0


Diese letzte Zeile

2021.10.29 09:27:56.273 2: HMCCU [CCU2] Update success=123 failed=0

bleibt immer dann aus, wenn nach einem Neustart der CCU das erste mal FHEM/HMCCU andockt. Erst nach einem erneuten shutdown restart von FHEM erscheint dann diese letzte Zeile.

Zwischen dem Start der CCU und dem (ersten) Start von FHEM liegen 10 Minuten, die CCU (virtualisierte RaspberryMatic) ist nach höchstens einer Minute aber bereits online und funktional.
Gruß,
Ralli

Proxmox 8.1 Cluster mit HP ED800G2i7, Intel NUC11TNHi7+NUC7i5BNH, virtualisiertes fhem 6.3 dev, virtualisierte RaspberryMatic (3.73.9.20240130) mit HB-RF-ETH 1.3.0 / RPI-RF-MOD, HM-LAN-GW (1.1.5) und HMW-GW, FRITZBOX 7490 (07.57), FBDECT, Siri und Alexa

theotherhalf

Hatte heute mal hier reingeschaut, nachdem ich meine Werte nicht mehr im Floorplan sah.
Die Readings haben sich in ihren Bezeichnungen wohl geändert und da ich per readingProxy alles aus den Devices auslese, war das etwas fummelig. Aber jetzt läuft es wieder.

Eine Frage abschliessend: Der Stromzählersensor HM-ES-TX-WM lässt sich per "get CCU createDev" nicht einbinden.
Das wird händisch gemacht?
FHEM Anfänger
HM CCU2 mit diversen Komponenten als Steuerung
FHEM mit Floorplan auf Raspi 3 (Raspbian Jessie)  zur Visualisierung (Heizung, Zustände, etc.) und angeschlossenen One-Wire Sensoren
Schnittstelle CCU2 - FHEM mit HMCCU
EBUSD Applikation auf Raspi 2 mit Anbindung an Vaillant Heizung