RaspberryMatic 3.75.7.20240420 – Neue Version

[MrPetz]

Hallo zusammen,

ich weiß nicht ob dies das richtige Forum für meine Frage ist, aber ich versuche es mal.
Ich habe hier eine recht umfangreiche Installation gesteuert über Raspberrymatic 3.75.7.20240420.
Nun habe ich einen neuen HMIP-RGBW Controller eingebunden.
Diesen kann ich über die Oberfläche Steuern und alles ist gut.
Wenn ich diesen aber aus einem Programm ansteuern will habe ich nur „Kanalaktion“ und eine Zahl von 1000 – 10200 K zur Auswahl.
Ich habe den Aktor schon gelöscht und wieder hinzugefügt, alles ohne Erfolg.
Ich müsste diesem doch Dimm-Zeiten, Helligkeitswerte usw. mitteilen können?

Hat jemand eine Idee wo hier der Fehler liegen könnte?
Danke schon mal für eure Hilfe!

...

Kleines Update:
Wenn ich den Controller neu anlerne und direkt ein Programm schreibe, ist der Kanal konfigurierbar.
Auffällig ist, nach „Kanalaktion“ kommt ein langes Feld auf das ich klicken kann um Einstellungen vorzunehmen.
Ab dem 2. Kanal kommt nach dem „Kanalaktion“ ein kusives „auf“ und das Wertefeld ist klein mit einer 1 die ich dann nur in 1000 – 10200 K ändern kann.
Ab dann keine Chance mehr etwas einzustellen bis zum nächsten Reset und neu anlernen des Controllers.
Das kann doch nur ein Bug sein?

[homematic-user-4711]

Hallo Jens,

ich habe das RaspberryMatic (RM) Add-On auf einem HomeAssistant mit RaspberryPi 4 installiert. Nachdem ich nun Probleme mit der WebUI habe, bin ich auf diesen Foreneintrag gestoßen. Mein RM läuft und auch meine installierten Geräte laufen. Einzig auf der linken Seite die Web-Oberfläche scheint nicht zu laden, was laut Deiner Beschreibung tatsächlich mit dieser Version zusammen hängt.
Ich habe ein umfangreiches HomeAssitant mit mehreren Add-Ons installiert, sodass ich nicht alle Add-Ons und Features testen kann. D.h. in der Zwischenzeit habe ich auf Deinem Add-On keine Änderungen mehr durchgeführt und damit die RM WebUI nicht mehr aufgerufen, dafür aber an anderen Stellen wie bspw. mit Node-Red.
D.h. nun nach 3 Wochen bemerke ich, dass ich ein Problem habe und könnte zwar die Sicherung zurückspielen, hätte aber meine Änderungen an anderer Stelle verloren. Wenn ich das richtig verstehe, dann muss ich nun auf das nächste Update warten wenn ich keinen Datenverlust haben möchte. Dummerweise muss/möchte ich ein defektes Gerät austauschen, was gerade nicht möglich ist.
Bleiben bei einer "Deinstallation" des Add-On die Geräte und Einstellungen gespeichert oder wäre dann auch alles weg, sodass ich tatsächlich auf die neue Add-On Version warten muss?

Vielen Dank und beste Grüße

[Fischermaen]

Ich habe diesen Thread gelesen und einiges umgesetzt, doch leider bin ich immer noch von folgendem Problem betroffen:

- Immer Abends (rund um Sonnenuntergang) beginnt der Duty Cycle zu steigen. Erst langsam und dann immer schneller bis auf 99%
- Gegen Mitternacht beruhigt sich wieder das System.

Was habe ich schon unternommen:

- Grundsätzlich arbeite ich mit Direktverknüpfungen wo immer das möglich ist. (Diese funktionieren zuverlässig, auch wenn der DC = 99%)
- Die wenigen Programme habe ich mehrfach gecheckt. Alle Auslöser stehen bei mir auf "Bei Änderung".
- Ich protokolliere den DC im Systemlog und habe die WebUI geschlossen
- Alle Aktoren, die die CCU (Raspberrymatic) erreichen, haben "Routing aktiv" = nicht angehakt
- Nur etwa 15 Geräte nutzen das Routing, dass von insgesamt 3 Steckdosen erledigt wird.

Ich würde gerne wissen, wie ich die Logs nutzen und analysieren kann, um auf die Ursache zu kommen.

Bitte ein paar Tips.

Vielen Dank am @Xel66 und PHundhausen für die Tipps. Das Fehlerlogbuch kann ich leider immer noch nicht vernünftig entschlüsseln. Mir ist nun aber folgendes aufgefallen: Meine Rolladen-Programme wurden ganztägig regelmäßig aufgerufen. Daraufhin habe ich diese abgesichert und nun werden sie tagsüber tatsächlich nur noch aufgerufen, wenn sich die Bedingungen geändert haben. Abends allerdings werden diese weiterhin immer dann aufgerufen, wenn der im Programm verwendete Lichtsensor seinen Status sendet.

Welchen Fehler übersehe ich?

[MichaelN]

Debugging Tips siehe Signatur. Mit dem Auslöseskript in jedem DANN findest Du heraus was dein Programm triggert

[PHundhausen]

Abends allerdings werden diese weiterhin immer dann aufgerufen, wenn der im Programm verwendete Lichtsensor seinen Status sendet.

Keine wirkliche Ahnung, da du nicht weißt, was das Programm wirklich triggert. Vermuten kann ich nur auf die Sonne.xxxxx, damit kenne ich mich überhaupt nicht aus, aber die stehen "bei Änderung" ...

Deswegen ist es auf alle Fälle ratsam, eine Art Protokoll zu integrieren, in dem du auslesen kannst, was dein Programm ausgelöst und welcher Zweig dabei genommen wurde.

Ich persönlich verwende dazu das Script / Konzept von Alchy: viewtopic.php?f=31&t=35686

[Fischermaen]

Ich habe das Script eingebaut und getestet. In "Status und Bedienung" - "Programme" wird regelmäßig die Auslösezeit aktualisiert, im Log steht aber nichts Ich bin einfach nur ratlos. Der Duty Cycle pendelt sich bei 55 % ein (vor der Version 3.75.6 waren es unter 30%).

[Baxxy]

Nur weil der Zeitstempel des Programms aktualisiert wird heißt das nicht das auch eines der Dann... ausgeführt wird.
Wenn du Alchy's Script in alle 3 Dann... eingefügt hast, und auch das drumherum korrekt angelegt hast, dann solltest du im Systemprotokoll sehen ob eines der Dann... durchlaufen wurde.

[Fischermaen]

Es wird keines der DANN durchlaufen. Was mich nur stutzig macht, ist der Umstand, dass bei Helligkeit > 70 Lux der Zeitstempel nur dann aktualisiert wird, wenn eine der Bedingungen zutrifft. Bei Helligkeit < 70 Lux aber wird der Zeitstempel im Takt der Aktualisierung durch den Helligkeitssensor aktualisiert.

[Baxxy]

Ich kann das Verhalten des Zeitstempels von Programmen nicht erklären.
Ich denke das kann (bei komplexeren Programmen) quasi niemand.

Der Zeitstempel ist m.E. auch irrelevant.
Wichtig ist nur ob ein Dann... Pfad durchlaufen wird. Da das wohl nicht der Fall ist, ist das gezeigte Programm m.E. nicht für deine DC-Probleme verantwortlich.

[Xel66]

Da das wohl nicht der Fall ist, ist das gezeigte Programm m.E. nicht für deine DC-Probleme verantwortlich.

Mich wundert eher, dass das Programm Behanghöhen ungleich 100% dauerhaft halten können soll. Eigentlich dürfte das ein Ballett sein und der Rollladen im Aktualisierungsintervall zwischen 0 bzw. 40% und 100% hin- und herfahren (weil durch die eingefügte Abfrage der Behanghöhe nach Ausführung der DANN die Bedingungsprüfung immer in die Prürfung ungleich 100% läuft). Wahrscheinlich ist es so kaputt, dass da irgendwas glücklicherweise nicht richtig greift.

Das Aktualisierungsintervall des Zeitstempels kommt von der Bedingungsprüfung des Helligkeitssensors, der innerhalb des Programms auf zwei verschiedene Helligkeiten (<70 und > 20000 lux) prüfen muss. Diese Prüfung ist Teil der Bedingungsprüfung des Programms und somit ist die Aktualisierung des Zeitstempels korrekt, da dieser bei jeder getriggerten Bedingungsprüfung aktualisiert wird, unabhängig davon, ob ein DANN oder SONST ausgeführt wird.

Gruß Xel66