Florian.Reinartz hat geschrieben: ↑27. Dez 2023 13:20
In allen *.map -Dateien hatte ich NULL= bereits eingetragen.
Allerdings nicht mir einem - sonder mit unterschiedlichem Text.
Mal mit "bitte warten..." mal mit "OK"
Siehste mal... lesen bildet (also mich...). Es steht ja gar nicht da, dass NULL das Problem ist, sondern dass MAP nicht installiert ist. Du musst die Map Transformation nachinstallieren, damit sie korrekt funktioniert. Falls die Transformation installiert ist, stimmt etwas ganz und gar nicht...
Florian.Reinartz hat geschrieben: ↑27. Dez 2023 13:20
In den Rules habe ich in den if-Sätzen auch immer eine Bedingung für NULL definiert um z.B. eine Division duch NULL zu vermeiden.
Ja, aber nein. openHAB wird niemals auch nur versuchen, durch NULL zu teilen, denn NULL bedeutet, es ist keine Zahl. openHAB wird also vorher einen Fehler melden. Es gibt aber noch andere Werte, die eine korrekte Berechnung verhindern, die von NULL abweichen, der korrekte Test lautet daher
damit wird geprüft, ob der Status von Item eine Zahl ist. Im Anschluss müsste man vor einer Division auf 0 prüfen (0 ist etwas anderes als NULL und nochmal was anderes als null)
Florian.Reinartz hat geschrieben: ↑27. Dez 2023 13:20
In der heizung.rules und ecovacs.rules habe ioch die Fehler schon gefunden.
Mit der deconz.rules bin ich noch auf Kriegsfuß...
Du kannst auch gerne Deine Rules zeigen
Florian.Reinartz hat geschrieben: ↑27. Dez 2023 13:20
Fehler in der mqtt.things bekomme ich schon seit OH2 angezeigt.
Allerdings erkenne ich gegenüber den Beispielen im WWW nich was ich falsch machen...
Sind es die geschweiften Klammern die alle Things nach der Bridge einfassen?
(mqtt.things im Anhang)
Du hast Dir definitiv viel zu viel Arbeit gemacht.
Der erste Punkt ist, Du hast zwei unterschiedliche Schreibweisen miteinander vermischt.
Wenn man Things mit einer Bridge per Textdatei definiert, gibt es zwei Möglichkeiten:
1. man definiert die Bridge und verweist bei jedem Thing auf diese Bridge. Sieht so aus:
Code: Alles auswählen
Bridge mqtt:broker:broker "Broker" [host="localhost"]
Thing mqtt:topic:broker:geraet1 "Gerät 1" (mqtt:broker:broker) [thing-config] {Channels}
Vorteil: Bridge und Broker können komplett getrennt voneinander existieren, z.B. auch in getrennten Dateien oder auch das Eine per UI, das Andere per Text. Nachteil: unheimlich viel Schreibarbeit (verglichen mit Möglichkeit 2)
2. Man definiert die Bridge und darunter alle Things. Das sieht so aus:
Code: Alles auswählen
Bridge mqtt:broker:broker "Broker" [host="localhost"] {
Thing topic geraet1 "Gerät 1" [thing-config] {Channels}
}
Man spart sich also nicht nur die Angabe des Bindings pro Thing, sondern auch den Teil der UID, der die Bridge angibt (den Du bei Deiner Topic Definition nicht genutzt hast, was eigentlich nicht erlaubt ist, aber zumindest unter OH2 funktionierte. Kann ursächlich für Dein Problem sein). Außerdem braucht es auch keinen Link zur Bridge, denn die ergibt sich ja aus der Hierarchie.
Vorteil also: viel weniger Tipparbeit. Nachteil: Alles muss in dieser einen Datei definiert werden. Also, bis auf die Things, die man dann trotzdem nach Möglichkeit 1 konfiguriert, denn die steht immer zur Verfügung
Da es aber ohnehin sinnvoll ist, alles, was zu einer Bridge gehört, auch zusammen mit dieser Bridge zu definieren, kann man diesen Nachteil auch als minder schwer ansehen.
Ein zweiter Punkt ist die Definition Deiner Topics und der Channels. Du brauchst andere Topics für die Rückmeldung und kannst dafür auf Channels verzichten. Außerdem sind ON und OFF ohnehin die korrekten Status für den onValue und den offValue, es ist also sinnlos, diese extra mit zu konfigurieren.
Ein Tasmota Schaltkanal sieht gewöhnlich so aus:
Code: Alles auswählen
Type switch : ch1 "TV Johanna" [ stateTopic="stat/Tasmota036/POWER", commandTopic="cmnd/Tasmota036/POWER" ]
Diese Definition reicht aus, um immer den korrekten Schaltzustand zu haben, gleich ob direkt am Gerät oder über openHAB gesteuert wird
stat/device/POWER ist die Antwort auf
cmnd/device/POWER und wird auch gesendet, wenn man die Taste am Gerät drückt oder über die Tasmota GUI schaltet.
Die Verbrauchsmessung ist auch so eine Sache. Tasmota speichert diese Daten aus gutem Grund nicht persistent (sonst ginge der Flashspeicher innerhalb weniger Stunden kaputt), was aber auch bedeutet, dass die Messdaten bei Stromausfall weg sind. Man wird also ohnehin anders vorgehen müssen, um sinnvolle Daten zu bekommen, im Zweifel wird man in openHAB selbst ein Item definieren, welches den Verbrauch kumuliert - und zwar indem ENERGY.Total ausgewertet wird. in der passenden Rule wird auf changed getriggert und der neue mit dem alten Wert verglichen. Ist der neue Wert kleiner als der alte Wert, so gab es zwischendurch einen Reset - warum auch immer - und es muss genau der Wert addiert werden, der geliefert wurde. Ist der Wert hingegen größer als der alte Wert, darf nur die Differenz addiert werden. Ungefähr so:
Code: Alles auswählen
when
Item changed
then
var mysum = (summernitem.state as Number) + (newState as Number)
if((newState as Number) > (previousState as Number)
mysum = mysum - (previousState as Number)
summenitem.postUpdate(mysum)
Diese Rule kann so gestaltet werden, dass sie sich um alle gleichartigen Items kümmert. Auf diese Weise kannst Du auf vier Channel pro Schaltkanal mit Messung verzichten und verlierst dabei nichts.
Bei ca. 40 Messstellen kommen natürlich 40 Items für die Summen hinzu, aber es sind ja vorher 160 Items weggefallen
und für die Optimierung, nur eine Rule zu benötigen kommen noch zwei Group Items dazu.
Florian.Reinartz hat geschrieben: ↑27. Dez 2023 13:20
Die Fehlermaledung mit den Frames ist auch schon "immer" da. Ich weiß, macht die Sache nicht besser...
Sieht aber so schön und übersichtlich aus... (siehe Wetter.png)
Allerdings habe ich grade gemerkt, wenn ich mit Group arbeite und einer Teil der Frames weg lasse... es sieht noch nahezu genau so aus.
Werde die Sitemap mal durcharbeiten.
Du hast Glück, dass die Sitemap überhaupt dargestellt wird. Ich kann Dir aber versichern (gerade mit dem Screenshot von Dir), das geht auch ohne Fehlermeldung
Florian.Reinartz hat geschrieben: ↑27. Dez 2023 13:20
Also... Snapshot 3.4.0
Der Befehl
Code: Alles auswählen
find $OPENHAB_USERDATA/ -exec grep -i '3.4.0-SNAPSHOT' /dev/null {} \;
schreibt etwa 20 Sekunden den Bildschirm voll.
Mit vorangestelltem sudo etwa 60 Sekunden...
Jede Zeile endet mit
": Ist ein Verzeichnis".
Im Verzeichnis /usr/share/openhab/addons habe ich zwei Dateien:
org.openhab.binding.icloud-3.4.0-SNAPSHOT.jar
org.openhab.binding.modbus.sungrow-3.4.5-SNAPSHOT.jar
Mehr habe ich jetzt nicht gefunden.
Habe noch mal über Samba und den TotalCommander gesucht.
Code: Alles auswählen
U:\srv\openhab-userdaa\cache\org_eclipse_osgi\18\dala\state.json
U:\srv\openhab-userdaa\cache\org_eclipse_osgi\famework.info_679
U:\srv \openhab-userdaa\jsondb\1672585137108-org.openhab.marketplace.json
U :\srv\openhab-userdaa\jsondb\1677345741454-org.openhab.marketplace.json
U:\srv \openhab-userdaa\jsondb\org.openhab.marketplace.json
U:\srv\openhab-userdaa\marketplace\kar\132989\org.openhab.binding.ecovacs-3.4.0-SNAPSHOT.kar
U:\srv\openhab-userdaa\lmp\kar\org.openhab.binding.ecovacs-3.4.0-SNAPSHOT\features.cfg
U:\srv\openhab-userdaa\lmp\kar\org.openhab.binding.ecovacs-3.4.0-SNAPSHOT\org\openhab\addons\bundles\org.openhab.binding.ecovacs\3.4.0-SNAPSHOT\maven-metadata-local.xml
U:\srv \openhab-userdaa\lmp\kanorg openhab .binding_ecovacs-3.4.0-SNAPSHOT\org\openhab\addons\bundles\org.openhab.binding.ecovacs\3.4.0-SNAPSHOT\org.openhab.binding.ecovacs-3.4.0-SNAPSHOT-features.xml
Das Bindinmg von Ecovacs scheint ein 3.4.0 Snapshot zu sein!
Aber es ist doch bestandteil des Binding-Paketes meiner OH3.4.4 Distibution ... hmmmm
Habe mal einen Screenshot gemacht (siehe Ecovacs.png)
Ah, ja, aber nein... Laut Doku gibt es das Binding überhaupt nicht für openHAB3 (sehr wohl aber für openHAB4), ich gehe davon aus, dass Du das irgendwie über Umwege installiert hast. Da das Binding aber da ist, sollte das auch keine großen Probleme auslösen.
Dieser Punkt muss also weiter erforscht werden - die Fehlermeldung ist nicht gesund, Du solltest unbedingt versuchen, solche Fehler weg zu bekommen.
Auch Dir eine gesegnete (Nach-) Weihnachtszeit und komm gut ins neue Jahr!
openHAB4.3.3 stable in einem Debian-Container (bookworm) (Proxmox 8.3.5, LXC), mit openHABian eingerichtet
