HMCCU 5.0 im SVN verfügbar

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

Vorheriges Thema - Nächstes Thema

Rewe2000

Hallo zap,

damit ich beim nächsten HMCCU Update keine Probleme bekomme und ich mich in Linux auch nicht so gut auskenne, wollte ich vorher prüfen ob ich noch etwas vorbereiten muss.
Ich denke ich sollte alle notwendigen Module schon am Raspi4 haben, oder irre ich mich da etwa?

reinhard@Fhem-Bookworm-SSD:~ $ apt list --installed
Auflistung... Fertig
....
libjson-c5/stable,now 0.16-2 arm64  [installiert]
libjson-perl/stable,stable,now 4.10000-1 all  [installiert]
libjson-pp-perl/stable,stable,now 4.16000-1 all  [installiert]
libjson-xs-perl/stable,now 4.030-2+b1 arm64  [Installiert,automatisch]
....

Gruß Reinhard
Fhem 6.3 auf Raspberry Pi4 SSD mit Raspbian Bookworm, Homematic, Homematic IP, CCU3 mit RapberryMatic, WAGO 750-880, E3DC S10E Hauskraftwerk, E3DC Wallbox, my-PV AC ELWA-E Heizstab, Fritz!Box 7590, KIA Bluelinky

zap

Sollte passen. Um sicher zu sein, darf folgender Befehl keinen Fehler produzieren:

perl -e "use JSON"
Wenn Du CPAN für die Installation der Module verwendest, dann sollte auch das gehen:

cpan -l | grep -i JSON
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

betateilchen

Zitat von: zap am 15 April 2024, 20:50:40Sollte passen. Um sicher zu sein, darf folgender Befehl keinen Fehler produzieren:

perl -e "use JSON"

Kann man auch direkt in der FHEM Befehlszeile testen:

{use JSON}
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

juemuc

Hallo zap,

nachdem die Anzeige des Wochenprogramms bestens funktioniert, würde ich gerne den nächsten "Schaltzeitpunkt" eines Thermostats auf Basis des aktuellen Zeitpunktes (Wochentag/Uhrzeit) ermitteln.
Hast Du einen Tipp für mich, wie ich Deine "Ausgabe" bzw. Dein Programmteil hierzu nutzen kann?

Viele Grüße
Jürgen
3x Sonos Play 1, 1x Sonos Arc + Sub, 1 Sonos-One, 1x Sonos Playbar
FB6690 + FB7490 mit 4x Dect 200 und 3 Dect-ULE-Thermostate,  raspberry3B+, HM Funkmodul HM-MOD-RPI-PCB, HM Klingelsensor HM-Sen-DB-PCB, HM (IP) Fensterkontakte und  Amazon Echo Dot,  piVCCU, pi OS (bookworm).

zap

Ich würde nicht die Ausgabe von get week-program verwenden sondern die Readings. Da stehen die Schaltzeiten ja drin. Du wirst aber nicht um eine kleine Perl-Funktion rum kommen.
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

juemuc

Hallo zap,

das hatte ich schon fast vermutet. Da ich nicht der große Programmierer bin, würde ich gerne bei Dir ein bisschen "abschreiben". Kannst Du mir sagen, wie bzw. wo Du die Infos für "get week-program" ermittelst? Dann kann ich zumindest lernen, wie die Zugriffe erfolgen, um die relevanten Daten zu ermitteln.

Danke im Vorraus.

Viele Grüße
Jürgen
3x Sonos Play 1, 1x Sonos Arc + Sub, 1 Sonos-One, 1x Sonos Playbar
FB6690 + FB7490 mit 4x Dect 200 und 3 Dect-ULE-Thermostate,  raspberry3B+, HM Funkmodul HM-MOD-RPI-PCB, HM Klingelsensor HM-Sen-DB-PCB, HM (IP) Fensterkontakte und  Amazon Echo Dot,  piVCCU, pi OS (bookworm).

kadettilac89

Ich habe zwei Verständnisfragen.

Im HMCCUCHN Device (bei mir Thermostat HM_CC_RT_DN) gibt es "set xxx update" mit dem die Readings R-ENDTIME_FRIDAY_(1-13) / R-TEMPERATURE_FRIDAY_(1-13) und die anderen Wochentage gefüllt werden. Gibt es eine Möglichkeit, diese Readings automatisch zu bekommen? Also jedes Mal wenn ich in der CCU3 einen Wert ändere? Werden diese Werte aktiv von der CCU3 gepusht wie viele andere Werte, oder muss man die manuell abholen?

Die andere FRage, kann ich zwei HMCCU Definitionen an eine CCU3 verbinden, oder würden die sich dann gegenseitig stören? Z. B. ein Testsystem und das produktive System würden die selbe CCU3 einbinden.

Sollte es abhängig vom Setup sein, ich nutze debmatic ohne jegliche Authentifizieurng oder Firewall. Fhem zum Testen in Docker im Host-MOde, somit auch keine Einschränkung auf Ports.



juemuc

Hallo,

ich nutze schon seit Jahren zwei HMCCU-Definitionen (Prod/Test) mit einer CCU3 (piVCCU3). Das ist kein Problem. Du musst halt beachten, dass du ggf. Devices aus dem Testsystem schaltest.

Viele Grüße
Jürgen.
3x Sonos Play 1, 1x Sonos Arc + Sub, 1 Sonos-One, 1x Sonos Playbar
FB6690 + FB7490 mit 4x Dect 200 und 3 Dect-ULE-Thermostate,  raspberry3B+, HM Funkmodul HM-MOD-RPI-PCB, HM Klingelsensor HM-Sen-DB-PCB, HM (IP) Fensterkontakte und  Amazon Echo Dot,  piVCCU, pi OS (bookworm).

kadettilac89

Zitat von: juemuc am 01 Mai 2024, 10:26:45ich nutze schon seit Jahren zwei HMCCU-Definitionen (Prod/Test) mit einer CCU3 (piVCCU3). Das ist kein Problem. Du musst halt beachten, dass du ggf. Devices aus dem Testsystem schaltest.
Danke

zap

Zitat von: kadettilac89 am 30 April 2024, 21:27:27Ich habe zwei Verständnisfragen.

Im HMCCUCHN Device (bei mir Thermostat HM_CC_RT_DN) gibt es "set xxx update" mit dem die Readings R-ENDTIME_FRIDAY_(1-13) / R-TEMPERATURE_FRIDAY_(1-13) und die anderen Wochentage gefüllt werden. Gibt es eine Möglichkeit, diese Readings automatisch zu bekommen? Also jedes Mal wenn ich in der CCU3 einen Wert ändere? Werden diese Werte aktiv von der CCU3 gepusht wie viele andere Werte, oder muss man die manuell abholen?

Die andere FRage, kann ich zwei HMCCU Definitionen an eine CCU3 verbinden, oder würden die sich dann gegenseitig stören? Z. B. ein Testsystem und das produktive System würden die selbe CCU3 einbinden.

Sollte es abhängig vom Setup sein, ich nutze debmatic ohne jegliche Authentifizieurng oder Firewall. Fhem zum Testen in Docker im Host-MOde, somit auch keine Einschränkung auf Ports.


Die "R-" Readings (die man per get config bekommt) sind Konfigurationsparameter. Diese werden von der CCU leider nicht automatisch aktualisiert. Einzige Möglichkeit wäre, in FHEM per "at" die Config regelmäßig abzuholen. Das sollte man aber nicht zu häufig machen, da es den Duty Cycle auf der CCU erhöht.
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

kadettilac89

Zitat von: zap am 02 Mai 2024, 10:41:25Die "R-" Readings (die man per get config bekommt) sind Konfigurationsparameter. Diese werden von der CCU leider nicht automatisch aktualisiert. Einzige Möglichkeit wäre, in FHEM per "at" die Config regelmäßig abzuholen. Das sollte man aber nicht zu häufig machen, da es den Duty Cycle auf der CCU erhöht.


Danke, das passt schon, ich mache es dann bei Bedarf manuell. Ich wollte nur sichergehen dass es nicht einen Parameter oder Möglichkeit gibt bevor ich es selber triggere.

Btw, mir ist beim Testen ein Fehler in der Doku aufgefallen.

Beim Beispiel wäre der richtige Port 7011 nicht 7010 (5000+2001+10).
rpcserverport <base-port>
Specify base port for RPC server. The real listening port of an RPC server is calculated by the formula: base-port + rpc-port + (10 * ccu-number).
Default value for base-port is 5400.The value ccu-number is only relevant if more than one CCU is connected to FHEM.
Example: If base-port is 5000, protocol is BidCos (rpc-port 2001) and only one CCU is connected the resulting RPC server port is 5000+2001+(10*1) = 7010.


tomcat.x

Zitat von: phoenix-anasazi am 22 Januar 2024, 12:08:03ich habe das gleiche Problem wie tomcat.x
Bei mir verlieren beide RPC-Server-Devices (HmIP und BidCos) die Zuordnung.
Ich habe meine Räume ebenfalls mit "->" strukturiert. Also im Prinzip identisch.

Kann es sein, dass das Problem nicht mit den strukturierten Räumen sondern mit dem Parameter delayedinit zusammenhängt? Den habe ich vor kurzem entfernt, seitdem bleibt die Raumzuordnung erhalten. Die gesetzte Zeit passt auch zum Zeitpunkt des Auftretens, so 5 Minuten nach Neustart.
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

phoenix-anasazi

Hi tomcat,

habe leider keine Benachrichtigung für diesen Thread bekommen. Wo hast du denn den Parameter gefunden? Konnte ihn weder am CCU-Device noch am RPC-Server finden.
Allerdings überlebt die Raumzuordnung der RPC-Server zurzeit die Nuestarts, ohne das ich etwas geändert habe.

tomcat.x

Hallo phoenix-anasazi,

laut Commandref:
define <name> HMCCU [<Protocol>://]<HostOrIP> [<ccu-number>] [nosync] [waitforccu=<timeout>] [ccudelay=<delay>] [delayedinit=<delay>]
Aber wenn Du den nicht kennst, hast Du ihn auch nicht gesetzt. Und das hat dann nichts damit zu tun. Vor allem, wenn es bei Dir jetzt auch weg ist ;-)

Viele Grüße
Thomas
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