@mickym Das iobroker Konzept verstehe ich noch nicht so ganz. Warum gibt es unterschiedliche roles und types? Wo werden die verwendet? In Jarvis konnte ich so einen mqtt-Datenpunkt auf ein Widget legen, musste es aber von Hand konfigurieren. Bislang konnte ich noch nicht rausfinden wie ein Datenpunkt beschaffen sein muss um automatisch z.B. als Schalter oder Licht dargestellt zu werden....

@hydrotec Im Endeffekt wäre sowas wie https://www.home-assistant.io/docs/mqtt/discovery ganz hübsch:

@mickym Es geht mir ja auch nicht um MQTT selbst, das ist ja nur das Transportmedium, sondern um iobroker. iobroker hat doch unterschiedliche roles/types/write und read-Eigenschaften (die ich bislang noch nicht so ganz verstehe). Warum und wozu kann ich die manuell anpassen?

Wenn es keinen Sinn macht, dann müsste es doch eigentlich ausreichen alles über "variable String" zu erledigen und es bräuchte gar keine unterschiedlichen roles und types?

@hydrotec Danke für die Infos.

Bislang schicke ich einfach irgendwelche Sachen an irgendwelche Topics, die werden "leider" nur als Zustandstyp Zeichenkette, Rolle variable angelegt:

Cool fände ich nun, wenn die rot umrandeten Felder per MQTT besetzt werden könnten:

Zum Beispiel über ein spezielles Topic, /iobroker/mqttconfig mit Inhalt:

{
  "common": {
    "name": "/devices/wb-adc/controls/lala1",
    "write": false,
    "read": true,
    "role": "switch",
    "type": "boolean"
  }
}

Das dann eben angelegt oder geändert wird sofern es das nicht gibt oder andere Werte enthält...

@gargano Verstehe ich leider nicht wirklich. Gibt es irgendwo ein Beispiel für sowas? Also eine Lampe die dem MQTT-Broker ihren aktuellen Zustand meldet (und wie der zugehörige Payload aussehen muss/sollte) und in iobroker ein Lampenicon auf das man draufdrückt und das dann je nach Zustand dem MQTT-Broker "was" schickt.
Oder gibt es für solche Dinge keinen "Standard", d.h. muss man dies alles selbst progammieren?

@gargano sagte in MQTT Topic/Payload Dokumentation:

@joe_d Der mqtt Adapter macht nichts weiter damit. Nur den Wert in den Datenpunkt schreiben. Bei mir werden die Heizungsdaten übermittelt. Die zeige ich dann in der Vis mit widgets und einer Grafik an.

Ok, ist mir nun auch gelungen:

Nur fehlt mir jetzt echt irgendwie ein Leitfaden.

Wie kann ich eine schaltbare Lampe (am Besten automatisch) mit MQTT hinzufügen?

@homoran Ja, ich kann auch den MQTT-Client Adapter nehmen. Und ich kann ja mit

mosquitto_pub -h 127.0.0.1 -t test/lampe/1/off -m "Lampe ist aus"

etwas an meinen Broker schicken. Was macht der MQTT-Client Adapter denn damit?

@gargano Das bedeutet?

Bei Homeassistant z.B. gibt es bei MQTT ein "Discovery", wenn man Meldungen in dem Format sendet werden z.B. Lichter usw. angelegt (https://www.home-assistant.io/docs/mqtt/discovery). Das ist dort alles schön beschrieben.

Hallo Zusammen,

habe bislang ein FHEM-System am laufen das ich eventuell mit iobroker ablösen möchte. An Hardware existiert bei mir

• ein AS1440 Stromzähler mit D0-Schnittstelle der Obis ausgibt aber kein SML spricht. Da FHEM nicht in der Lage war den Stromzähler "gescheit" auszulesen (den kann man von 300Baud auf 9600Baud umschalten) habe ich ein C-Programm geschrieben das dies vom Timing her richtig macht und an die Werte einfach auf die Konsole schreibt. Die werden dann mittels Pipe in FHEM geschrieben.
• eine Junkers Heizung mit Heatronic3-Protokoll das an einem USB-Adapter von Norbert S. hängt (https://www.mikrocontroller.net/topic/317004?page=single). Die wurde als einziges direkt von FHEM unterstützt, da Norbert S. etwas dafür geschrieben hatte.
• eine Junkers Lüftungsanlage die Modbus-TCP spricht aber leider ziemlich dämlich zu betreiben ist. Zum Beispiel kann man hier nicht einfach sagen "Stufe 4 für die nächsten 30 Minuten", sondern man muss per Modbus-TCP aus dem Automatikprogramm nach Manuell schalten. Dann die Stufe ändern. Dann einen Timer "außerhalb" (FHEM) setzen, der nach der Zeit die Kiste wieder ins Automatikprogramm setzt. Dafür musste ich in FHEM einen eigenen Modbus-Gerätetreiber schreiben
• 8 serielle Modbus Stromzähler DDS238-1ZN an einem Modbus2USB-Adapter. Die Zähler liefern 10 Werte, unter anderem den aktuellen Strom. Hier war es in FHEM nicht möglich alle 8 Zähler einfach so schnell wie möglich hintereinander abzufragen. Unter 10 Sekunden gab es immer wieder Fehler. Auch hier habe ich ein C Programm geschrieben das jetzt innerhalb einer Sekunde alle 8 Zähler auslesen kann und die Werte auf die Konsole schreibt wo diese mittels Pipe in FHEM geschrieben werden
• 1 seriellen Modbus für den Gaszähler-Impulszähler der direkt in FHEM alle 10 Sekunden ausgelesen wird
• Selbstbau IO-System mit 128 Eingängen und 128 Ausgängen das über USB gesteuert wird und auch über USB die aktuellen Stati ausgibt. Hierüber werden sämtliche Lampen an- und ausgeschaltet, Fenster- und Tür- und Klingelkontakte, Schlösser und Bewegungsmelder ausgewertet, Rollladen und Garagentor rauf- und runtergefahren. Dazu gab es ein serielles IO-Modul in FHEM das ich aber leider erst von Bugs befreien musste bevor ich es einsetzen konnte

Bei FHEM ist mir aufgefallen das diese SmartHome-Lösung eigentlich gar nicht in der Lage war dumme Hardware "intelligent" einzubinden. Ein Modbus der nur alle 10 Sekunden irgendwas pollen kann ist schön für ein Gerät das eine Super Schnittstelle über Modbus bietet und nur "bedient" werden muss aber eine Katastrophe für z.B. meine Junkers "Lüftungssteuerung".

Aber auch beim einfachen Auslesen von Stromzählern bin ich mit den Standardmodulen von FHEM sofort auf die Nase gefallen. Beim AS1440 muss man nachdem man auf 9600 Baud umschaltet 400ms warten. Das habe ich in Perl unter FHEM nicht sauber hingekriegt. Genauso das Auslesen von 8 Modbus Stromzählern "einfach so schnell wie möglich hintereinander", ist wohl schon eine Spezialanwendung.

So musste ich relativ viel sowohl an FHEM an Modulen rumbasteln und erstellen (Perl ) wie auch externe Programme schreiben die die Daten aufbereiten.

Diese (negativen) Erfahrungen brachten mich zu der Frage: Warum besteht eine Smarthome-Steuerung eigentlich nicht grundsätzlich nur aus einem MQTT-Broker der sämtliche Daten bereitstellt und externe Programme speisen einfach den MQTT-Broker? Super wäre in so einem Fall wenn Topic und Payload einfach irgendwie sein könnten und auf dem Adapter könnte man das einfach konfigurieren oder als Template hinterlegen.

Die Lösung nur mit MQTT-Broker möchte ich jetzt mit iobroker probieren.

Der iobroker läuft schonmal soweit, ein mosquitto ist installiert und auch der MQTT Broker/Client-Adapter ist einsatzbereit.

Aus meiner naiven Sicht muss ich also "nur noch" z.B. meinen beiden Zähler-Auslese-Programmen beibringen Ihre Daten an den MQTT-Broker zu senden.

Und nun meine Fragen:

• Kann der Adapter auf unterschiedliche Payloads oder Topics konfiguriert werden
• Braucht es einen bestimmten Aufbau vom Topic? Wenn ja, wo ist das dokumentiert?
• Braucht es einen bestimmten Aufbau vom Payload? Wenn ja, wo ist das dokumentiert?
• Wie funktioniert ein Mapping von Gerätearten? Also wie wird die Rückmeldung von einem Fenster erkannt? Wie die Rückmeldung einer Tür?
• Wie sieht Topic oder Payload für verschiedene Gerätearten aus? Fenster? Türen? Rollladen? Bewegungsmelder?

Ich habe dazu leider so gut wie nichts dazu gefunden unter https://github.com/ioBroker/ioBroker.mqtt/blob/master/README.md

Gruß

Jochen