HMCCU 5.0 Beta verfügbar

Begonnen von zap, 05 Januar 2020, 19:49:52

Vorheriges Thema - Nächstes Thema

zap

Zitat von: eurofinder am 02 September 2021, 13:21:59
@zap:
Upps, sorry. Ich habe die Datei oben berichtigt.

Gruß
eurofinder

Wie vermutet (befürchtet). Die CCU meldet LEVEL so:

LEVEL: FLOAT [R,W,E] [Visible,Sticky] RANGE=0...1.01 DFLT=0

Und so sollte es aussehen:

LEVEL: FLOAT [R,W,E] [Visible,Sticky] RANGE=0...1.01 DFLT=0 UNIT=100%

In dem Fall muss Du Dir mit dem Attribut ccuscaleval behelfen:

ccuscaleval LEVEL:0:1:0:100

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

eurofinder

RPI3+; Raspbian Buster Lite; RPI-RF-MOD; piVCCU3, HMIP-eTRV-2, HmIP-SWDO, HmIP-SRH, HmIP-STHO, HmIP-SLO

Jamo

Zitat von: zap am 02 September 2021, 19:58:20
Die Version 5.0 steht in Github zur Verfügung. Installation siehe erster Beitrag in diesem Thread.

Neben Bugfixes gibt es folgende neuen Funktionen:

Neuer Befehl "get detectDev" in HMCCU. Sollte ein Gerät nicht korrekt angelegt werden oder funktionieren, kann die Ausgabe dieses Befehls mir helfen, den Fehler zu finden.

Neues Attribut "createDeviceGroup". Wenn dieses Attribut gesetzt ist, werden FHEM Devices, die alle zum gleichen CCU Gerät gehören, beim Anlegen mit "get create" oder "get createDev" automatisch der gleichen Gruppe zugewiesen. Der Name dieser Gruppe wird mit diesem Attribut definiert.

Wenn man z.B. eine Fernbedienung mit 6 Tasten hat und diese mit "get create" anlegt, erzeugt HMCCU 6 HMCCUCHN Devices (1 je Taste). Mit createDeviceGroup = "%t %n" werden alle 6 Devices einer Gruppe zugeordnet, deren Name aus "DeviceType DeviceName" zusammengesetzt wird (die Platzhalter werden ersetzt, siehe auch Commandref).

Nachtrag: Folgende Geräte sollten jetzt beim Anlegen automatisch erkannt werden: HmIP-SAM, HmIP-SPDR, HmIP-FCI1
Hallo Zap,
die version 5.0 läuft bei mir unauffällig, bei mir funktioniert alles - danke!
Bullseye auf iNUC, Homematic + HMIP(UART/HMUSB), Debmatic, HUEBridge, Zigbee/ConbeeII, FB, Alexa (fhem-lazy), Livetracking, LaCrosse JeeLink, LoRaWan / TTN / Chirpstack

Rudy

Ich nutze einen HmIP-SPI mit der aktuellen (beta)-Version 5.0. Dabei gibt es das Problem, dass sich der Präsenzmelder über FHEM zwar inaktiv setzen lässt aber nicht mehr auf aktiv. Scheint das gleiche Problem wie hier zu sein. Wenn ich stattdessen mit "set Melder datapoint 1.PRESENCE_DETECTION_ACTIVE true" arbeite funktioniert es. Die hier gefundene Lösung funktioniert nicht (vermutlich, da ich die aktuellere Beta nutze).

Der Rest läuft problemlos.

zap

Ja, das ist ein Bug. Ist bei meinem Bewegungsmelder auch so.
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

Timmäää

#650
Neues Update für 5.0 im GitHub Rep. sowie FHEM contrib SVN.

zap

Ja, ich hatte gestern keine Zeit mehr, es hier anzukündigen.

- Der Bug bei der Aktivierung/Deaktivierung von Bewegungs-/Präsenzmeldern ist behoben
- RPC-Server und I/O Devices können nun ohne Nebenwirkungen umbenannt werden
- Wenn ein I/O Device gelöscht wird, werden auch die zugehörigen RPC-Devices gelöscht
- Wenn ein Attribut eines laufenden RPC Device geändert/gesetzt wird, erscheint ein Hinweis, dass die Änderung erst nach einem Neustart des RPC-Servers wirksam wird

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

Maista

@zap Moin

Ich habe die HMCCU 5.0 installiert und probiert was die Wetterstation nun so treibt.

Die svHmIP-Variablen werden bei "get values" weiterhin nicht mit ausgegeben.
Nur sporadisch werden diese aufgefrischt (Systemstart?).

Als ccureadingfilter ist .* gesetzt.

Wenn ich jetzt als Versuch in den ccureadingfilter nur ein "svHmIPRainCounterToday_1609" eintrage und dann bestätige, sehe ich im
Event Monitor das scheinbar die Anfrage an die CCU3 funktioniert?
2021-09-10 23:04:06 HMCCUCHN HM.OG.bk.WE.Sensor svHmIPRainCounterToday_1609: 0.0
2021-09-10 23:04:06 HMCCUCHN HM.OG.bk.WE.Sensor 17.1
2021-09-10 23:04:06 HMCCUCHN HM.OG.bk.WE.Sensor rssipeer: N/A
2021-09-10 23:04:06 HMCCUCHN HM.OG.bk.WE.Sensor devstate: ok
2021-09-10 23:04:06 HMCCUCHN HM.OG.bk.WE.Sensor activity: alive
2021-09-10 23:04:06 HMCCUCHN HM.OG.bk.WE.Sensor battery: ok
2021-09-10 23:04:06 HMCCUCHN HM.OG.bk.WE.Sensor rssidevice: -73
2021-09-10 23:04:06 HMCCUCHN HM.OG.bk.WE.Sensor hmstate: 17.1
2021-09-10 23:04:06 HMCCUCHN HM.OG.bk.WE.Sensor Regen: NEIN
2021-09-10 23:04:06 Global global ATTR HM.OG.bk.WE.Sensor ccureadingfilter svHmIPRainCounterToday_1609


Die Variablen welche groß geschrieben werden nicht ausgegeben.
Nur die klein geschriebenen.
Kann das sein obwohl nur "svHmIPRainCounterToday_1609" im ccureadingfilter  steht?

Falls das mit HMCCU nicht machbar ist abzufragen muss ich mal schauen ob man das in der CCU als Systemvariable setzen kann.
Dann könnte ich das von der d_ccu aus per AT abholen. Klappt schon mal mit der CPU-Temperatur :=)

Danke für deine Arbeit.

Gruß
Gerd

zap

Das svm... ist eine (verknüpfte) Systemvariable. Ich habe leider kein Gerät, das sowas verwendet. Daher ist das Blind-Entwicklung.
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

Maista

#654
@zap

Betreffend HmIP-SWO-PR und Variablen svHmIPRainCounterToday_xxxx, svHmIPRainCounterYesterday_xxx, svHmIPSunshineCounterToday_xxxx und svHmIPSunshineCounterYesterday_xxx.

Ich hab im iobroker Forum https://forum.iobroker.net/post/197178 etwas gefunden mit dem man sich das zusammenbasteln kann.
Hierzu muss man in der CCU vier neue Variablen erzeugen lassen. Diese können dann per get ausgelesen werden.
Nun kann man mit einem Notify, wenn die WX-Station abgefragt wird (trigger auf z.B. rssidevice), die angelegten vier neuen Systemvariablen abfragen.

defmod HM.OG.bk.WE.Sensor_notify_1 notify HM.OG.bk.WE.Sensor rssidevice:.* get d_ccu vars Var_Regenmenge_heute;;\
get d_ccu vars Var_Regenmenge_gestern;;\
get d_ccu vars Var_Sonne_heute;;\
get d_ccu vars Var_Sonne_gestern;;


Das Problem dieser internen Variablen scheint ja unabhängig von der Home-Automationssoftware zu sein  :o
Bei io-Broker hat man das wohl hinzubekommen indem man die Versteckten Variablen frei gibt.

Soweit funktioniert bei mir die Wetterstation. Mehr ist allerdings auch noch nicht angemeldet.

Danke und Gruss
Gerd

zap

Es gibt ein Update in Git/SVN: Der Befehl "get vars" liest nun auch versteckte Variablen.

Übrigens: Ein AT zum regelmäßigen Lesen der Variablen ist nicht erforderlich. Stattdessen das Attribut "ccuGetVars" verwenden. Beispiel: Alle 60 Sekunden die Variablen lesen, die mit "sv" anfangen:

attr ccuGetVars 60:^sv

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

Maista

#656
Hallo @zap,

das scheint an mir vorbei gegangen zu sein. Ich hab alles mögliche gelesen das die Leute eben nicht drauf zugreifen konnten.
Aber das dies nun doch geht war mir neu.
Sporadisch wurden diese "sv_Variablen" ja angezeigt aber nicht immer aktualisiert.

Wenn die Versteckten Variablen aber erst nach dem jetzigen Update funktionieren ist es auch klar das es mit meiner Aktuellen nicht funktioniert.
Diese "sv_Variablen" werden dann im jeweiligen zugehörigen Device angezeigt?

Zitatattr ccuGetVars 60:^sv
In der HMCCU anzugeben und auch mehrere (RegEx) möglich?
Oder im jeweiligen Device?

Danke , Gerd

PS: Kannst Du das Betreff auf "HMCCU 5.x" abändern ;)?

Maista

#657
@zap

Manuell aus dem SVN die beiden aktuellen PMs geladen.
Die "sv-Variablen" werden nun in HMCCU angezeigt (siehe Bild)!
Zitatattr d_ccu 60:^sv|^Temperatur_CCU3
funktioniert scheinbar auch.
Zumindest wird mir die CPU-Temperatur als Reading aktualisiert :D. Sonne oder Regen gibt es derzeit nicht.
Update: Die sv-Variablen werden ebenfalls aktualisiert :)

In HMCCU kann ich
Zitatget d_ccu vars sv.*
eingeben. Es wird dann ein Fenster mit den Werten angezeigt.

In HMCCUCHN funktioniert z.B. 
Zitatget HM.OG.bk.WE.Sensor datapiont svHmIPRainCounterToday_1609
nicht.
2021.09.12 00:22:44 1 : HMCCUCHN [HM.OG.bk.WE.Sensor] Error CMD = Write((datapoints.Get("HmIP-RF.00185BE9A57631:1.svHmIPRainCounterToday_1609")).Value())
2021.09.12 00:22:44 1 : HMCCUCHN [HM.OG.bk.WE.Sensor] HMCCUCHN: HM.OG.bk.WE.Sensor Execution of CCU script or command failed


Auch wenn die "sv-Variablen" Interne sind, sollten diese doch aber im jeweiligen Device angezeigt/abgerufen werden können!?
Du meintest ja das funktioniert nicht, wie man aber bei HMCCU sieht scheint das ja doch möglich zu sein?

Wenn das nicht klappt, macht es aber doch kein Sinn diese im Device anzuzeigen.
Will ich die jeweiligen Readings beisammen haben muss ich nun erst mit einem "setreading" die Werte aus dem Device d_ccu (HMCCU) in das Device der Wetterstation übertragen.

Ich weis das es immer einfach geredet ist wenn man es nicht machen muss, aber deine Module sollten ja Userfreundlicher werden  ;)

Gruss Gerd

zap

Anscheinend zeigt ioBroker die Werte auch nicht am Gerät an, sondern nur als Variable im Rega-Adapter.

Siehst Du die Variablen, wenn du für das Device "get deviceinfo" ausführst?

Mein Problem: Irgendwie muss ich herausfinden, welche Variable welchem Gerät zugeordnet 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

Maista

@zap

Ja im Wetterstations-Device sehe ich die sv-Variablen und auch die selbst angelegten in der ccu3.
Siehe Bild (derzeit Mobil)