zigbee2mqtt - Beginner Fragen - Sonoff ZBDongle-P

[udo1toni]

Mach bitte keine Bilder. Es gibt (bis auf die Items) in allen Bereichen eine Code Ansicht in Textform, die ist wesentlich sinnvoller als Pixelorgien.
Falls es tatsächlich mal nötig sein sollte, ein Bild zu sehen, kannst Du das leicht nachreichen, evtl. wenn es um Details einer Ansicht in der Main UI, HABPanel oder Basic UI geht, für doe Konfiguration kann man so git wie immer die Codeansicht verwenden (wie gesagt - mit Ausnahme der Items)

Es sieht irgendwie so aus, als sei nur ein Teil der Konfiguration korrekt übernommen worden. Du kannst versuchen, das Thing zu entfernen und neu finden zu lassen.

[Boris099]

Na das ist ja ein Ding, das habe ich noch gar nicht gesehen mit dem Code.
Also als ich eben noch mal geschaut habe, ist das Thing mit seinen Channels plötzlich komplett da, hat wohl einen Tag Zeit benötigt
um sich zu entwickeln
Der Code zeigt folgendes, der essentielle Trigger channel der fehlte, ist nun da:

Code: Alles auswählen

UID: mqtt:homeassistant_zigbee2mqtt_5F0x2c1165fffe96ba3a:72559ba08d:zigbee2mqtt_5F0x2c1165fffe96ba3a
label: ZigButton1
thingTypeUID: mqtt:homeassistant_zigbee2mqtt_5F0x2c1165fffe96ba3a
configuration:
  topics:
    - device_automation/0x2c1165fffe96ba3a/action_off
    - device_automation/0x2c1165fffe96ba3a/action_on
    - sensor/0x2c1165fffe96ba3a/action
    - sensor/0x2c1165fffe96ba3a/battery
    - sensor/0x2c1165fffe96ba3a/linkquality
  basetopic: homeassistant
bridgeUID: mqtt:broker:72559ba08d

Das ist Verwirrend!!
Jetzt habe ich eine Verständnisfrage bzgl. Thing, Channel, Item, Topic bin ja neu in OH3.
Also ich habe jetzt schon das Thing und die Channels und Topics aber keine items?
1. Muss ich nun neue items anlegen (im Channel sehe ich "Add link to item") um sie in meinen rules verwenden zu können,
oder kann ich die channels direkt ansprechen? Ich gehe mal davon aus, das ich diese items benötige wie in OH2 auch
(aber dort kam ich bei ZWAVE-things auch ohne explizite items in der .items Datei durch).
2. Und benötige ich nun Points, Equipments, Locations, Model, Pages (eine Page musste ich ja anlegen)
oder ist das nur der neuen OH3 Oberfläche geschuldet und kann alles noch später erstellt bzw. auch hoffentlich nachträglich
modifiziert werden?

Hmmmm,
sicher viele Möglichkeiten, ich frage mich jedoch, ob das eigentlich einfach zu verstehen ist oder ich schon zu alt bin

Jetzt doch noch ein Bild
Wichtig: Kann ich hier Item Name und Label frei benennen?
Muss ich Type und Category setzen bzw. ist das später auch nochmal änderbar?
Muss ich semantic class und property setzen bzw. ist das später nochmal änderbar

Bildschirmfoto von 2023-01-02 11-14-43.png

[udo1toni]

Jetzt habe ich eine Verständnisfrage bzgl. Thing, Channel, Item, Topic bin ja neu in OH3.

Määääp, Ausrede. Things wurden mit openHAB2 eingeführt. (und auch mqtt stand ab OH2.3 offiziell als mqtt2 Binding zur Verfügung und mqtt1 war ab diesem Zeitpunkt als deprecated markiert.)

In openHAB1 gab es Bindings und Items. Ein Item ist ein Element, welches eine Eigenschaft auf dem openHAB Bus beschreibt bzw. zugänglich macht.
Du kannst auf dem openHAB Bus beliebig Items anlegen und nutzen.

Interessant wird es aber erst, wenn Du dieses Item mit einer Hardware verkoppelst. Unter openHAB1 geschah dies ausschließlich über die Definition der Hardware Funktion, welche an die Itemdefinition angeklebt wurde.
Das Binding selbst wurde aber an anderer Stelle konfiguriert, nämlich in der openhab.cfg, dort gab es für jedes Binding einen Konfigurationsbereich.
Da man gewöhnlich nur einen Bruchteil der Bindings nutzt, schleppte man also jede Menge Ballast mit. In einem ersten Schritt wurde deshalb die Konfiguration in einzelne <bindingname>.cfg Dateien aufgespittet, die in einem Ordner services abgelegt wurden.
Nun stand aber immer noch ein Teil der Hardwaredefinition in einer Datei, ein anderer Teil (der itemspezifische) in einer oder gar mehreren anderen Dateien.
Außerdem wollte man Autodiscovery haben.

Also wurde das Thing Modell als zusätzliche Abstraktionsebene eingeführt (wie gesagt - schon mit openHAB2). In einem Thing wird also die komplette Hardware abgebildet. Anschließend muss man nun die Items mit den gewünschten Aspekten der Hardware verknüpfen, das geschieht über die Channel.
Dabei muss der Itemtyp zum Channeltyp passen.
Vorteil dieser Trennung: ich kann mehrere Channel mit dem selben Item verknüpfen. Genauso kann ich auch mehrere Items mit dem selben Channel verknüpfen. es gibt also eine N:M Beziehung. In den meisten Fällen wird man 1:1 Verknüpfungen nutzen, aber 1:M oder N:1 ist in bestimmten Situationen genauso zulässig und wichtig.

Wenn Du einen Channel in openHAB verwenden willst, kommt es auf den Channel an Grundsätzlich musst Du eine Verknüpfung zu einem Item erstellen, IMMER ist das der Fall, wenn Du den Inhalt anzeigen willst (weder Sitemap noch Main UI oder HABPanel unterstützen den Zugriff auf Channel) oder einen Channel steuern möchtest.
Es gibt aber auch Channel, die Du gar nicht mit einem Item verknüpfen KANNST. Als Beispiel mag das Astro Binding dienen, wleches diese Channel als erstes genutzt hat, das sind die Event Channel. Ein Event ist immer ein Zeitpunkt, z.B. der Beginn des Sonnenaufgangs oder der Zeitpunkt, wenn ein Taster gedrückt wird. Der Event Channel sendet dann das Ereignis exakt zu dem Zeitpunkt. Ein verknüpftes Item stünde also immer auf "nix", würde für den Bruchteil einer Millisekunde den Zustand auf "ereignis" wechseln und sofort wieder auf "nix" zurück. Es ist somit witzlos, da der Zustand keine Rolle spielt.
Wenn Du also im Zusammenhang mit ZWAVE von Channels berichtest, die Du "einfach so" ohne Item verwenden konntest, handelt es sich um Channel, mit denen Du Ereignisse in Rules verwendet hast, Zustände in ZWAVE kannst Du damit aber nicht anzeigen.

Was tatsächlich in openHAB3 als große Neuerung dazu kam (abgesehen von der Main UI natürlich) ist das (optionale) Semantic Model. Im Semantic Model werden Eigenschaften von Items beschrieben und die Items werden hierarchisch angeordnet. Das Semantic Model ermöglicht es damit, vollautomatisch Ansichten zu den Items zu generieren.
Eine Page musst Du zu keinem Zeitpunkt anlegen, es sei denn, Du willst eine Page nutzen. Wenn Dir eine Sitemap reicht, kannst Du Semantic Model und Pages links liegen lassen. Beides lässt sich auch nachträglich konfigurieren, die einzigen Parameter, die nicht nachträglich angepasst werden können, sind die IDs, das gilt für alle Bereiche (Items, Channel, Things, Bridges, Pages, Sitemaps, Rules...)

Wie gesagt wäre das Bild unnötig gewesen Die einfache Antwort lautet: Wenn Du einen Parameter bearbeiten kannst, kannst Du ihn (im Rahmen der Bedingungen) frei konfigurieren. Immer. An jeder Stelle.
Die Bedingungen sind: IDs müssen mit einem Buchstaben beginnen. Als Zeichen sind nur das englische Alphabet, die arabischen Ziffern sowie der Unterstrich erlaubt.
Die UID eines Channels setzt sich aus mehreren Blöcken zusammen, die Binding, Anbindung,Typ und ChannelID beinhalten. jeder dieser Bereiche ist mit einem Doppelpunkt getrennt. In der UI ist es nicht möglich, ungültige IDs zu setzen. Jede UID muss eindeutig sein, das heißt, sie muss sich immer in mindestens einem der Bereiche von allen anderen UIDs unterscheiden. Das heißt, ich kann z.B. eine mqtt Bridge mit der ID bridge definieren und auch eine zwave Bridge mit der ID bridge definieren, denn die eine trägt die UID zwave:bridge und die andere die UID mqtt:bridge.
Solange man nicht mehrere Bridges in einem Binding verwendet, ist der generische Name mehr als ausreichend. Ebenso kann ich z.B. zwei mqtt Things definieren, welche z.B. als ID sonoff1 und sonoff2 verwenden. Beide können nun einen Channel mit der ID power nutzen, denn die UID lauten dann mqtt:bridge:topic:sonoff1:power und mqtt:bridge:topic:sonoff2:power.

Label dürfen alle Zeichen enthalten, evtl. gibt es aber Zeichen, die nicht korrekt dargestellt werden (das hängt dann vom verwendeten Browser ab) oder die besondere Aufgaben haben (man denke an die eckigen Klammern in Item Labels, sofern die Items über eine Textdatei definiert sind).

IDs lassen sich nachträglich nicht mehr ändern, Du musst dann den entsprechenden Teil löschen und neu anlegen. Das ist einer Der Gründe, warum ich die textliche Definition der in der UI vorziehe. Auf die Schnelle zum Testen gerne üder die UI, ordentlich immer und ausschließlich über .items, .things usw., aber das ist natürlich Geschmackssache.