Beiträge von fnu007

Wenn man die Cloud Anbindung nicht abschalten könnte, hätte kein Shelly Aktor den Weg zu mir gefunden ... dazu kommt das interne, "übergeordnete" Systeme ja auch unabhängig und übergreifend Dinge zusammenbringen.

Naja, Besserwissen ist in der Nachbetrachtung immer einfach 🧐 sehe von Euch beiden keine Eingabe weiter oben ...

Ich habe auch nicht "überraschend" geschrieben (!), sondern unerwartet. Der Stromverbrauch im 24V DC Betrieb ist wohl (deutlich) höher als ich aus den Unterlagen herrausrechnen vermochte. Die Lösung ist an sich ohne Shelly 25 sinnvoll nutzbar, mit doch eher unbrauchbar. Da muss ich mich wohl nach was effizienterem aus dem 868MHz Funkbereich umschauen ...

Würde der Shelly 25 per MQTT evtl. effizienter als im CoIoT Betrieb arbeiten? Unabhängig davon ob der jetzt den Rolladenbetrieb damit überhaupt kann ...

Mal ein Update hier, da ich das erst im "Trockenaufbau" längere Zeit testen will. Beim Stromverbrauch sind nicht die Rohrmotoren das Problem, die Kalkulation zur Akku Kapazität haben wir gut hinbekommen bzw. wird vorr. übertroffen im Real-Betrieb. Die LiFePO4 Akkus haben 6Ah, in etwa das was die LiFePO4 Starterbatterie meines Bikes auch hat, ungefähr 3x soviel wie die verschiedenen Kauflösungen haben (um 2,1Ah). Letztere sind dann je nach Hersteller mit zw. 20 und 80 Laufzyklen pro Tag auf Akku angegegeben ...

Mein Problem scheint etwas unerwartet der Shelly 25 zu sein, der lutscht mir die großen Akkus in 7-9 Tagen leer, ganz ohne Motor-Action ... 🤔😒

Zitat

Was mir noch auffällt im 24V Modus zeigt der Shelly25 hier keine Uhrzeit an ... ?

Hat sich erledigt, habe den Shelly25 eben mal auf Factory resetted und neu eingebunden, nachdem immer wieder unmotivierte Restarts gezeigt hat. Nun zeigt er auch die Uhrzeit an, im 24V Modus.

Zitat

Stellt sich die Frage, ob die Hinderniserkennung (Obstacle Detection) im 24V Modus auch nicht funktioniert ... ?

Hat sich auch erledigt, da wenn eingeschaltet man ja Leistungsaufnahme definieren kann, bei welcher die Erkennung aktiv werden soll. Das geht natürlich nicht im 24V Modus ...

Ja, die Richtung passt schon, nur biss'le klein und noch nicht hübsch genug ... 😉 ... und ich brauche auch einen mit (Aufputz-)Gehäuse, da ich den nicht mit/an der Elektronik montieren möchte.

Was mir noch auffällt im 24V Modus zeigt der Shelly25 hier keine Uhrzeit an ... ?

Im 24V Modus gibt es keine Energiemessung, daher auch keine Kalibrierung. Diese benötigt wohl die Energiemessung um die Endpositionen festzustellen, wenn der Motor auf den Endschalter gelaufen ist, abgeschaltet wurde und der Energiebedarf dann eben gleich Null geht.

Stellt sich die Frage, ob die Hinderniserkennung (Obstacle Detection) im 24V Modus auch nicht funktioniert ... ?

So, gestern kamen die Motoren, eben mal einen Trockenaufbau verkabelt

diy_rollo_test.png

Einen hübschen weißen "<|0|>" bzw. "1-0-2" habe ich leider noch nicht gefunden ... scheint das Schwierigste zu werden ... 😂

Der Vollständigkeit halber, für das Beispiel Sonoff könnte der "channel" zum MQTT "thing" so aussehen:

Type number : rssi "RSSI" [
   stateTopic="tele/sonoff_th16/STATE",
   transformationPattern="JSONPATH:$.Wifi.RSSI" ]

Hier offensichtlich auch mit dBm RSSI to "qualityofservice" transformation.

Ja, nein, Workaround muss jetzt nicht sein, das OH Shelly Binding ist doch sehr gut gelungen, und funktioniert tadellos. Auch wenn man beim Schalten subjektiv den Eindruck eines wirklich kurzen "lags" hat ...

Nun denn, MQTT @ OH3 aufgarbeitet und wieder ein paar Verbesserungen am OH best practise gefunden. Werde denn Test-MQTT-Shelly noch eine Weile laufen lassen, liegt eh sonst nur in der Schachtel.

Zum Parsen finde ich nicht mehr als ich da sehe.

Und ja, kann sein "qualityofservice"/RSSI gibt es nicht per MQTT, nur per CoIoT. Letzteres hatte mich erst drauf gebracht diese Telemetrie Daten auch für meine EnOcean Aktoren einzusammeln, in Detail-View anzuzeigen, inkl. Transformation von dBm RSSI in eine "qualityofservice" Anzeige.

Eben mal gesucht, Beispiele für RSSI per MQTT habe ich keine für Shelly gefunden, aber andere Geräte u.a. scheinbar auch Sonoff.

Schade, das Schalten per Software scheint was "knackiger" zu sein per MQTT.

Aber der Ausflug war nicht umsonst, hab endlich die korrekte Lösung gefunden, Bridge und Things in getrennten Dateien unterzubringen. Hat mich schon immer gestört, wenn ich nur an einem Aktor was ändere das auch die Bridge anschließend neu geladen werden musste ... evtl. gehe ich noch weiter und trenne Aktoren, Schalter und Sensoren in weitere Dateien ...

So, der Factory Reset mit aktueller FW ändert das Bild direkt ... sieht aus wie bei AlexAn auch ohne Telemetrie Kanäle ...

mqtt_expl_shelly1_after_reset.png

Downgrade ist einfach mit dem Shelly Manager von OH ... kann ich mal versuchen. Zuerst würde ich eher noch mit der aktuellen FW auf Factory zurücksetzen ...

Aber, ich sehe bei Dir jetzt auch nur Schaltkanal bezogenes, keine Telemetrie Topics, z.B. RSSI oder last status o.ä. ... ?

"External Switch" kommt sicher auch nur, wenn das am Shelly eingeschaltet wurde ...

Wie hast Du "qos" gesetzt?

Ja, schon klar, habe ich gestern auch nicht gleich gesehen, bis es sich ergab, das ein reboot des Shelly 1 hier gut tat ... 🧐🙂

Aber sieh selbst, das bekomme ich aktuell zu sehen, das "command" topic tauchte z.B. erst auf, als ich den Shelly ein paar Mal geschalten hatte ...

mqtt_expl_shelly1.png

Der läuft doch schon ... aber der Shelly 1 liefert lt. diesem nur den Schaltkanal (relay & input) und offensichtlich keine weitere (eigene) Telemetrie.

Und zeigt scheinbar auch erst alles ganz korrekt an, wenn man den Shelly einmal benutzt hat ... zumindest beim topic "relay" ... "input" bediene ich aktuell nicht ...

So, der Test "Shelly 1" lässt sich per MQTT @ OH3.1.0 schalten. Den Embedded MQTT Broker gibt es wohl seit OH3 nimmer, bei 2.5 war er noch da, eben meine Erinnerung. Aber Mosquitto war dann schnell aufgesetzt.

Die OH MQTT Dokumentation lässt "Spielraum zur Eigeninitiative" ... 😏😲 ... es reicht z.B. den Broker als Bridge zu definieren, es braucht hier z.B. keine "broker.things" wo der Broker nochmals ohne Prefix Bridge drin steht.

Nun mal bisschen Testen und versuchen rauszufinden was an Channels gibt, z.B. WiFi RSSI, last status update, ... und ob sich Verbesserungen für die mqtt.things finden.

Eigentlich bin ich eher kein Freund permanent geöffneter Verbindungen, aber auch nicht davon Geräten den Status "abjagen" zu müssen ...

Regelmäßiges "ich bin noch da" und "hab diesen oder jenen Status" bzw. "ich habe deinen Befehl bekommen und ausgeführt" ist m.E. eigentlich ein guter Resourcen-schonender Weg.

AlexAn Ja, sicher, mal sehen wo es hingeht. Aber am Ende will man doch nur ein paar Dinge automatisieren und komfortabler machen und nicht zum Mond fliegen ... 🧐😂

Interessantes Flow-Chart hast Du da ...

Zitat

MQTT kann direkt aktiviert werden. Einen Broker hast du?

Ist eingebaut in OH, muss nur aktiviert werden ...

Zitat

MQTT ist auch Eventbasierend

Ja, fühlt man sich gleich irgendwie zu Hause als (alter) EnOcean Nutzer. Definition in OH auch sehr ähnlich, Bridge mit Things als Untereinheiten. Grad schonmal einen Shelly1 lose verkabelt zum Test ...

MQTT der orig. Shelly FW "is good to go" oder muss ich mich mit Tasmota(?) befassen?

Zitat

KeepAlive eines Gerätes über MQTT kenn ich sonst von keinem anderen Dienst.

Ok, das ist ein Punkt, mit nativ binding kennt man tatsächlich eher ein "go dark" ... 😂 ... ist bei EnOcean auch Standard, lasse mir den letzten Kontakt da sogar anzeigen ...

Hallo,

ich platziere meine rein informative Frage mal hier, da ich openHAB nutze. Und gleich die Bitte, das ist kein Aufruf zu flame wars, ich bin nur neugierig, warum manche MQTT nutzen und andere nicht.

Meine Smarthome Basis ist openHABian 3.1.0 auf einem Raspberry Pi 3. Ich definiere alle things, items, sitemap und rules etc. ausschließlich auf CLI, ASCII Ebene. Macht mir die Sicherung der Konfiguration einfacher und Upgrades sind bei mir auch einfach nur Neu-Installationen, mit Restore dieser Dateien. Insofern würde mich das Pflegen etwaiger MQTT Definitionen in Dateien nicht wirklich schrecken ...

Was mich nun interessiert, gibt es entscheidende Vorteile/Nachteile Shelly Aktoren mit MQTT anzusprechen gegenüber dem nativen openHAB Shelly Binding? Können die MQTT Geräte evtl. peer-to-peer kommunizieren, also eine Art Mesh bilden? Oder ändert sich eigentlich "nur" die Ansprache via WiFi, also zw. MQTT Protokoll zu native binding, wenn ich das richtig verstehe, CoIoT basiert?

Dank schon mal für Eure Antworten.

Regards