MQTT WLAN Glühlampe Farbe ändern

[Kahzia]

Hallo zusammen,


ich habe bereits einige Steckdosen mit Tasmota geflasht und über MQTT eingebunden.
Allerdings fällt mir die neulich erworbene Glühlampe fürchterlich schwer.

Es handelt sich um eine Gosund WLAN Glühlampe RGBW.
Tasmota ist bereits geflasht und die Lampe lässt sich einwandfrei über die Console und über das Tasmota UI ansteuern.

Jetzt habe ich das Problem, dass ich im MQTT Explorer die Lampe zwar sehe, aber nicht weiß wie die z.B den Dimmer anspreche (von der Syntax her)
Bei den Steckdosen war es immer relativ einfach übe rden MQTT Explorer zu sehen.

Ich hoffe auf dem angehängten Bild erkennt man alles.
Bisher konnte ich mir das ganze so zusammenreimen, dass im oberen Beispiel die Steckdose erreichbar ist unter tele/name/sensor -> und dann über JSON das was ich möchte (Power,Voltage etc.)

Bei der Lampe unten fehlt dieser Teil komplett.
Ich habe bisher nur einen Switch zum ein und ausschalten hinbekommen.

Code: Alles auswählen

Type switch : ch9               "AN/AUS"          [ stateTopic="stat/Tasmota_Lampe_01/POWER", commandTopic="cmnd/Tasmota_Lampe_01/POWER", on="ON", off="OFF" ]

Wie jetzt der Dimmer dafür aussieht weiß ich nicht, dass ist auch meine Frage.

Code: Alles auswählen

 [ stateTopic="stat/Tasmota_Lampe_01/SENSOR", transformationPattern="JSONPATH:$.ENERGY.Dimmer" ]

funktioniert leider nicht. wäre auch zu einfach gewesen

Wie kann ich rauskriegen, wie die Syntax für den Dimmer oder die Farbe ist ?
Ich drehe mich aktuell nur noch im Kreis.... ich hoffe jemand kann mir einen Tipp geben.

LG
Kahzia

[udo1toni]

Schau in die Doku von Tasmota, da ist das haarklein erklärt.

Möglicherweise wirst Du nur Konfigurationsbeispiele für HA finden, aber die Plattform spielt ja nun keine Rolle, es geht ja nur um Topics und deren Payload.

Und weil ich immer ein fürchterlicher Nörgler bin… Es handelt sich um eine LED-Lampe - oder RGB(W) LED Lampe.
Eine Glühlampe hat eine Wolfram Wendel in einem evakuierten geschlossenem Glashohlraum (in verschiedenen Formen, z.B. pilzförmig, kerzenförmig oder auch birnenförmig)…


Gesendet von iPad mit Tapatalk

[Kahzia]

Schau in die Doku von Tasmota, da ist das haarklein erklärt.

Möglicherweise wirst Du nur Konfigurationsbeispiele für HA finden, aber die Plattform spielt ja nun keine Rolle, es geht ja nur um Topics und deren Payload.

Und weil ich immer ein fürchterlicher Nörgler bin… Es handelt sich um eine LED-Lampe - oder RGB(W) LED Lampe.
Eine Glühlampe hat eine Wolfram Wendel in einem evakuierten geschlossenem Glashohlraum (in verschiedenen Formen, z.B. pilzförmig, kerzenförmig oder auch birnenförmig)…


Gesendet von iPad mit Tapatalk

da hast du natürlich recht, ich habs mir beim schreiben schon gedacht
War aber ehrlich gesagt zu schreibfaul in dem Moment

Die Erklärung ist für mich nicht ganz schlüssig, ich glaube das Konzept habe ich wohl nicht ganz verstanden.
Der MQTT Explorer müsste doch in der Lage sein, alle Topics abzufragen.
Ich weiß nur nicht wie ich das anstelle, mit -v oder ähnlichem reagiert das Gerät leider nicht.
Zu 99% mache ich es aber auch einfach falsch.
Im Internet werde ich nahezu 0 fündig, zumindest ziehe ich nirgendwo Infos raus die ich verwerten kann.

Hast du noch einen TIpp wie ich an die unbekannten Topics komme ?

LG
Kahzia

[udo1toni]

Nein, wie kommst Du darauf? der MQTT Explorer hat nur Kenntnis über die Topics, die zum Broker gelangen. Ein Tasmota Device wird aber niemals Command Topics senden, die werden ausschließlich zum Empfang verwendet.
Wenn der HA-Modus aktiv ist (SetOption19 1) publisht Tasmota allerdings Informationen zur Autokonfiguration. In manchen Fällen funktioniert das sogar ganz gut, ob das bei RGBW Lampen der Fall ist, müsstest Du aber ausprobieren. Im HA-Modus unterscheiden sich die Topics von den üblichen Tasmota Topics (mindestens zum Teil), es nutzt also nichts, die Struktur manuell abzubilden und SetOption19 wieder auf 0 zu setzen.

[Kahzia]

hm ich weiß auch nicht wie ich darauf komme, ich hab das konzept beim lesen nicht ganz verstanden bisher...
Die SetOptions hatte ich garnicht gesehen gehabt, die sind gut erklärt auf tasmota.github
Mit deiner Setoption konnte ich tatsächlich im MQTT Explorer einiges in Erfahrung bringen.

Der Dimmer ist unter STATE eingegliedert.
Bedeutet wenn ich das Konzept verstandne habe müsste ich diesen erreichen unter

Code: Alles auswählen

Type number : ch9Dimmer     "Dimmer Test"   [ stateTopic="stat/Tasmota_Lampe_01/Dimmer"]

-> funktioniert leider nicht, vermutlich weil ich es noch nicht verstanden habe...
Auf der Sitemap verwende ich einen Slide um Werte zu übertragen.

Da mir die Syntax einfach verdächtig aussah, habe ich mich versucht an der alten zu orientieren.
Die hätte ich dann so abgeleitet:

Code: Alles auswählen

[ stateTopic="stat/Tasmota_Lampe_01/Dimmer", transformationPattern="JSONPATH:$.Dimmer", commandTopic="/cmnd/Tasmota_Lampe_01/Dimmer"]

leider habe ich damit auch noch keinen Erfolg.

Ich sehe meinen Fehler leider nicht.

LG
Kahzia

[udo1toni]

Wie gesagt... Die Ausgaben, die Du erhältst, wenn Du SetOption19 1 setzt, sind nicht unbedingt für den manuellen Betrieb geeignet. Stattdessen sollte der Dimmer dann automatisch in der Inbox auftauchen.

Aber noch mal zur Ausgabe in Deiner Grafik: Links steht das Topic, bzw. ein Teil des Topic, nämlich Tasmota_Lampe_01/STATE.
Davor fehlt noch das stat/, welches vermutlich im Filter eingetragen ist. Das Topic lautet also vollständig

stat/Tasmota_Lampe_01/STATE

Und dieses Topic liefert ein JSON Payload, einen Teil davon kann man direkt rechts neben dem Gleichheitszeichen sehen, einen weiteren Teil in der Detailansicht, die allerdings auch nicht vollständig ist.
Tipp an dieser Stelle: Ein Bild mag mehr sagen als tausend Worte, aber wenn es um Exaktheit geht, geht nichts über die reine Textform, als Text, und vollständig. Auch der MQTT Explorer erlaubt es, das Payload herauszukopieren...

Über das command Topic sagt das Payload überhaupt nichts aus. Wohl aber die Doku... https://tasmota.github.io/docs/Commands/#light dort findest Du tatsächlich Dimmer als Topic (abgesehen von prefix und Name des Device), aber auch Color und (vor allem) HsbColor. openHAB verwendet intern auch HSB. Auch das mqtt Binding bietet einen Color Channel, den Du dann auf HSB konfigurieren kannst.

Und wenn Du das Payload genauer anschaust, findest Du dort auch das Gegenstück. Das, was ich im Bild erkennen kann, lässt mich als JSONPath allerdings eher $.HSBColor vermuten.
Tipp an dieser Stelle: Es gibt Online Tester, bei denen man das Payload per Zwischenablage einfügen und anschließend den Pfad ausprobieren kann. Oder man nutzt ohnehin schon VSCode, dann kann man JSONPath StatusBar als Plugin installieren. Ist dieses Plugin installiert, so reicht es, das Payload in eine Datei mit Endung .json. einzufügen (die Datei muss nicht gespeichert werden... sie muss nur in VSCode geöffnet sein). Nun setzt man den Cursor auf den gesuchten Wert und kann in der Statuszeile das notwendige absolute JSONPath Statement ablesen.

[Kahzia]

puh, ich glaube ich bin noch sehr weit davon entfernt zu verstehen wie die LED Lampe mit MQTT einzubinden ist.
Kann das nicht auch so einfach wie mit der Steckdose sein

Ich wusste garnicht, dass man MQTT Geräte auch in der Inbox findet -> in der Tat ich konnte allerdings nur den Color Channel erwischen.
Auch hat sich das komplette Format im MQTT Explorer danach geändert (ist ja nicht schlimm)

Die JSON Path Status Bar hab ich mir installiert im VSCODE -> aber ich glaube ich habe nie wirklich JSON Path benutzt oder ?
Oder ich bin zu doof die Erweiterung zum laufen zu kriegen.

Die Commands habe ich (denke ich) schon soweit verstanden.
Mir ist zumindest bewusst, wie ich alle Werte im Payload über JSON Path verändere.
als bsp.

Code: Alles auswählen

http://192.168.178.129/cm?cmnd=Dimmer%2050

oder für Color

Code: Alles auswählen

http://192.168.178.129/cm?cmnd=Color%205

usw.

Aktuell benutze ich OH3, ich bin ehrlich ich finde OH3 etwas umständlich mit den Channels oder es ist die fehlende Übung.
Zumindest erhalte ich nur einen Color Channel der aber auch funktioniert.
Vom Pfad unterscheid sich dieser komplett zu meinen bisherigen.
-> siehe Screenshot.
Channel:

Code: Alles auswählen

mqtt:homeassistant_058E1D:myMQTTBroker:058E1D:058E1D_5FLI_5F1#color (Color)

wo kommt das homeassistant her ? ist das eine freie Bezeichnung von OH wenn man das ganze über die Inbox konfiguriert ?


Die LED Lampe taucht jetzt im MQTT Explorer unter einem komplett neuen Reiter auf.
homeassistant -> light -> 058E1D_LI_1 (wohl die Bezeichung der Lampe)

Ich hab mal den Payload jetzt kopiert

Code: Alles auswählen

{"name":"Tasmota","stat_t":"tele/Tasmota_Lampe_01/STATE","avty_t":"tele/Tasmota_Lampe_01/LWT","pl_avail":"Online","pl_not_avail":"Offline","cmd_t":"cmnd/Tasmota_Lampe_01/POWER","pl_off":"OFF","pl_on":"ON","stat_val_tpl":"{{value_json.POWER}}","uniq_id":"058E1D_LI_1","dev":{"ids":["058E1D"]},"bri_cmd_t":"cmnd/Tasmota_Lampe_01/Dimmer","bri_stat_t":"tele/Tasmota_Lampe_01/STATE","bri_scl":100,"on_cmd_type":"brightness","bri_val_tpl":"{{value_json.Dimmer}}","rgb_cmd_t":"cmnd/Tasmota_Lampe_01/Color2","rgb_stat_t":"tele/Tasmota_Lampe_01/STATE","rgb_val_tpl":"{{value_json.Color.split(',')[0:3]|join(',')}}","fx_cmd_t":"cmnd/Tasmota_Lampe_01/Scheme","fx_stat_t":"tele/Tasmota_Lampe_01/STATE","fx_val_tpl":"{{value_json.Scheme}}","fx_list":["0","1","2","3","4"],"clr_temp_cmd_t":"cmnd/Tasmota_Lampe_01/CT","clr_temp_stat_t":"tele/Tasmota_Lampe_01/STATE","clr_temp_val_tpl":"{{value_json.CT}}","whit_val_cmd_t":"cmnd/Tasmota_Lampe_01/White","whit_val_stat_t":"tele/Tasmota_Lampe_01/STATE","whit_val_scl":100,"whit_val_tpl":"{{value_json.White}}"}

ich hoffe der ist erträglich zu lesen.

meine Logik wäre immernoch, ich müsste das Gerät doch erreiche unter dem StateTopic:

Code: Alles auswählen

stateTopic="stat/Tasmota_Lampe_01/

richtig ?

danach würde ich definieren, welchen Teil ich beschreiben möchte.
In dem Fall den Dimmer:

Code: Alles auswählen

stateTopic="stat/Tasmota_Lampe_01/Dimmer"

auch noch richtig ?
oder müsste noch ein /STATE hinter Tasmota_Lampe_01 ?

Wenn ich dann zusätzlich noch Pattern mitgebe:

Code: Alles auswählen

transformationPattern="JSONPATH:$.Dimmer"

würde das doch exakt zum Payload passen oder ?
dieser verlangt doch value_json.Dimmer

so wäre meine Logik jetzt.
Ich hoffe ich bin nicht komplett auf dem absteigendem Ast.

LG
Kahzia

[udo1toni]

Deine "Logik" ist immer noch falsch

Es gibt kein stateTopic stat/Tasmota_Lampe_01/, dies ist nur der erste Teil des Topics. Ein Topic ist immer der gesamte Pfad.
Du kannst es Dir wie ein Verzeichnis vorstellen, in dem Dateien liegen. stat/Tasmota_Lampe_01/ ist das Verzeichnis, aber keine Datei.
Aber um das gleich klarzustellen: Nein, das sind keine Dateien und keine Verzeichnisse. Es geht nur darum, es zu veranschaulichen.
Du könntest also in dem "Verzeichnis" verschiedene "Dateien" finden. Die "Datei" STATE (Groß/Kleinschreibung ist wichtig!) enthält dann das JSON Objekt als Payload. Eventuell kommt das JSON Objekt aber auch nur über das Topic tele/Tasmota_Lampe_01/STATE, das legt zumindest Dein JSON Objekt nahe, hier mal "aufgehübscht":

Code: Alles auswählen

{
    "name": "Tasmota",
    "stat_t": "tele/Tasmota_Lampe_01/STATE",
    "avty_t": "tele/Tasmota_Lampe_01/LWT",
    "pl_avail": "Online",
    "pl_not_avail": "Offline",
    "cmd_t": "cmnd/Tasmota_Lampe_01/POWER",
    "pl_off": "OFF",
    "pl_on": "ON",
    "stat_val_tpl": "{{value_json.POWER}}",
    "uniq_id": "058E1D_LI_1",
    "dev": {
        "ids": [
            "058E1D"
        ]
    },
    "bri_cmd_t": "cmnd/Tasmota_Lampe_01/Dimmer",
    "bri_stat_t": "tele/Tasmota_Lampe_01/STATE",
    "bri_scl": 100,
    "on_cmd_type": "brightness",
    "bri_val_tpl": "{{value_json.Dimmer}}",
    "rgb_cmd_t": "cmnd/Tasmota_Lampe_01/Color2",
    "rgb_stat_t": "tele/Tasmota_Lampe_01/STATE",
    "rgb_val_tpl": "{{value_json.Color.split(',')[0:3]|join(',')}}",
    "fx_cmd_t": "cmnd/Tasmota_Lampe_01/Scheme",
    "fx_stat_t": "tele/Tasmota_Lampe_01/STATE",
    "fx_val_tpl": "{{value_json.Scheme}}",
    "fx_list": [
        "0",
        "1",
        "2",
        "3",
        "4"
    ],
    "clr_temp_cmd_t": "cmnd/Tasmota_Lampe_01/CT",
    "clr_temp_stat_t": "tele/Tasmota_Lampe_01/STATE",
    "clr_temp_val_tpl": "{{value_json.CT}}",
    "whit_val_cmd_t": "cmnd/Tasmota_Lampe_01/White",
    "whit_val_stat_t": "tele/Tasmota_Lampe_01/STATE",
    "whit_val_scl": 100,
    "whit_val_tpl": "{{value_json.White}}"
}

Man kann schön sehen, dass alle States stat_t, bri_stat_t, rgb_stat_t, fx_stat_t, clr_temp_stat_t und whit_val_stat_t jeweils über tele/Tasmota_Lampe_01/STATE rückgemeldet werden. Dieses Topic enthält auf jeden Fall ein JSON Objekt, welches mindestens die Objete
POWER, Dimmer, Color, Scheme, CT und White enthält, jeweils mit den passenden Werten, wobei POWER ON sein dürfte, sobald die Lampe nicht komplett aus ist. Color ist die RGB-Steuerung, Scheme kann mit den Werten 0 - 4 gesteuert werden. fx als Beschreibung legt nahe, dass so entweder Farbwechsel oder auch vorprogrammierte Einstellungen abgerufen werden können. CT ist die Farbtemperatur und White ist der Weiß-Kanal.

Die commandTopics stehen ebenfalls im Klartext da

tele/ gibt, wie erwähnt, zyklisch den Wert aus, es ist aber möglich, dass tele/Tasmota_Lampe_01/STATE hier zusätzlich bei Statusänderungen ausgegeben wird.

Die http-Aufrufe haben übrigens nichts mit mqtt oder jsonpath zu tun.

[Kahzia]

Ich glaube jetzt hat es klick gemacht
Meine Logik hat sich jetzt geändert zu :

Code: Alles auswählen

Type dimmer : Dimmer	"Dimmer Test"           [ stateTopic="tele/Tasmota_Lampe_01/STATE", commandTopic="cmnd/Tasmota_Lampe_01/Dimmer" ]

Ich hoffe das war jetzt nicht nur purer Zufall, dass der Dimmer funktioniert...
Unseren Thread hab ich jetzt glaub ich 20x gelesen und immer wieder versucht zu verstehen

Für den heutigen Abend, bin ich schonmal begeistert das der Dimmer funktioniert.

Braucht man immer zwingend ein item zu dem thing ?

Ich verstehe nicht so ganz, wofür das Item benötigt wird.
Klar, das Item ist verknüpft mit der Sitemap und kriegt natürlich den Input von der Sitemap aber wie gelangt der Input zum Thing mit der Syntax ?

DimmerTest2 erhält den Wert der Sitemap und der Channel führt dann DimmerTest aus ? woher weiß aber DimmerTest welchen Value ich übergebe ?
Das erschließt sich mir nicht so ganz, weil ich ja mit mqtt:topic auf beide Topcis zugreife ? also STATE und command Topic ?!
Da bin ich raus... das würde mich interessieren, wie das funktioniert.
.item

Code: Alles auswählen

Dimmer DimmerTest2 {channel="mqtt:topic:Tasmota_Lampe_01:DimmerTest"}

und noch nebenbei gefragt, seit ich die LED Lampe über die Inbox hinzugefügt habe, bekomme ich bei Bedienung ständig Warnungen angezeigt im OH Log.

Code: Alles auswählen

2021-10-11 01:06:56.636 [WARN ] [t.generic.ChannelStateTransformation] - Transformation service JINJA for pattern {{value_json.POWER}} not found!

2021-10-11 01:06:56.636 [WARN ] [t.generic.ChannelStateTransformation] - Transformation service JINJA for pattern {{value_json.Color.split(',')[0:3]|join(',')}} not found!

2021-10-11 01:06:56.639 [WARN ] [ab.binding.mqtt.generic.ChannelState] - Command '{"Time":"2021-10-11T00:06:56","Uptime":"0T08:36:44","UptimeSec":31004,"Heap":27,"SleepMode":"Dynamic","Sleep":10,"LoadAvg":107,"MqttCount":1,"POWER":"ON","Dimmer":60,"Color":"152,153,112,0,0","HSBColor":"62,27,60","White":0,"CT":166,"Channel":[60,60,44,0,0],"Scheme":0,"Fade":"OFF","Speed":1,"LedTable":"ON","Wifi":{"AP":1,"SSId":"Raspberry","BSSId":"DC:39:6F:14:1E:B0","Channel":1,"Mode":"11n","RSSI":92,"Signal":-54,"LinkCount":1,"Downtime":"0T00:00:03"}}' not supported by type 'ColorValue': {"Time":"2021-10-11T00:06:56","Uptime":"0T08:36:44","UptimeSec":31004,"Heap":27,"SleepMode":"Dynamic","Sleep":10,"LoadAvg":107,"MqttCount":1,"POWER":"ON","Dimmer":60,"Color":"152,153,112,0,0","HSBColor":"62,27,60","White":0,"CT":166,"Channel":[60,60,44,0,0],"Scheme":0,"Fade":"OFF","Speed":1,"LedTable":"ON","Wifi":{"AP":1,"SSId":"Raspberry","BSSId":"DC:39:6F:14:1E:B0","Channel":1,"Mode":"11n","RSSI":92,"Signal":-54,"LinkCount":1,"Downtime":"0T00:00:03"}} is not a valid string syntax

2021-10-11 01:06:56.642 [WARN ] [ab.binding.mqtt.generic.ChannelState] - Command '{"Time":"2021-10-11T00:06:56","Uptime":"0T08:36:44","UptimeSec":31004,"Heap":27,"SleepMode":"Dynamic","Sleep":10,"LoadAvg":107,"MqttCount":1,"POWER":"ON","Dimmer":60,"Color":"152,153,112,0,0","HSBColor":"62,27,60","White":0,"CT":166,"Channel":[60,60,44,0,0],"Scheme":0,"Fade":"OFF","Speed":1,"LedTable":"ON","Wifi":{"AP":1,"SSId":"Raspberry","BSSId":"DC:39:6F:14:1E:B0","Channel":1,"Mode":"11n","RSSI":92,"Signal":-54,"LinkCount":1,"Downtime":"0T00:00:03"}}' not supported by type 'PercentageValue': Unknown String!

2021-10-11 01:10:23.453 [WARN ] [ab.binding.mqtt.generic.ChannelState] - Incoming payload '{"Version":"9.5.0(tasmota)","BuildDateTime":"2021.06.17 08:28:30","Module or Template":"Gosund WB4","RestartReason":"External System","Uptime":"0T08:40:11","Hostname":"Tasmota_Lampe_01-3613","IPAddress":"192.168.178.129","RSSI":"88","Signal (dBm)":"-56","WiFi LinkCount":1,"WiFi Downtime":"0T00:00:03","MqttCount":1,"LoadAvg":99}' not supported by type 'NumberValue'

Die Meldung ist häufig Syntax Fehler oder Unknown String, obwohl ich eigentlich als bsp garnichts angelegt habe zu PercentageValue oder ähnlichem.
Im Moment ist nur Color über die Inbox belegt.
Die Warnungen treten aber auch auf, wenn ich den Dimmer betätige, also tritt es nicht nur beim Inbox Item auf.

Der Dimmer funktioniert "manuell" über die .things Datei.

LG

[udo1toni]

Ich glaube jetzt hat es klick gemacht
Meine Logik hat sich jetzt geändert zu :

Code: Alles auswählen

Type dimmer : Dimmer	"Dimmer Test"           [ stateTopic="tele/Tasmota_Lampe_01/STATE", commandTopic="cmnd/Tasmota_Lampe_01/Dimmer" ]

Das ist nicht ausreichend! Deshalb zeigt es auch eine Fehlermeldung (siehe unten)… Du musst noch eine incommingTransformation setzen, und zwar „JSONPATH:$.Dimmer“ - Die JSONPATH Transformation muss installiert sein.

Ich hoffe das war jetzt nicht nur purer Zufall, dass der Dimmer funktioniert...

Die Hälfte funktioniert (die abgehende… Du kannst steuern, bekommst aber keine ordentliche Rückmeldung wegen der fehlenden Transformation)

Braucht man immer zwingend ein item zu dem thing ?

Ja.

Ich verstehe nicht so ganz, wofür das Item benötigt wird.

Aaaalsooo: Wenn Du über openHAB etwas steuern möchtest, dann brauchst Du ein passendes Binding. Das Binding stellt die Schnittstelle zur Physik her, ob nun über Ethernet, Serielle Schnittstelle oder wie auch immer. Um konfigurieren zu können, welches Gerät gesteuert wird - jedes Binding erlaubt immer die Anbindung mehrerer Devices - legst Du für jedes Device ein Thing an. Ein Device hat oftmals (nicht immer) verschiedene Eigenschaften, die entweder gesteuert oder ausgewertet werden können (oder auch beides gleichzeitig…). Für jede dieser Eigenschaften wird ein Channel angelegt.
Bis zu diesem Punkt sind die Devices alle Binding spezifisch, und noch wichtiger: Du hast an dieser Stelle lauter einzelne Channel, die aber nichts mitweinender zu tun haben.
Nun soll aber alles gemeinsam gesteuert werden. Dazu müssen alle Channel auf den openHAB Bus (eigentlich steht das B in openHAB für Bus…) Dieser Bus hält die Status (openHAB selbst ist stateless), nimmt Befehle entgegen und leitet diese an die beteiligten Channel weiter. Items sind also die „Speicher“ der Eigenschaften der Devices auf dem openHAB Bus. Alles, was Du auswerten oder steuern möchtest, muss zwingend auf den openHAB Bus und somit als Item angelegt werden.
Es gibt eine Ausnahme dieser Regel, das sind Event Channel. Ein Event Channel sendet ein Ereignis, er triggert also zu einem bestimmten Zeitpunkt, hat aber keinen gültigen Status - im Gegensaltz zu den gewöhnlichen Channels.

Im Thing hast Du nur auf die Channel Zugriff, die auch verlinkt sind - das ist in der UI einfach dazu gebaut, um es bequemer zu haben.

Das erschließt sich mir nicht so ganz, weil ich ja mit mqtt:topic auf beide Topcis zugreife ? also STATE und command Topic ?!

Die Namen sagen es schon, aber noch mal zur Erläuterung: Es gibt hier eine Kommunikation in zwei Richtungen. Das stateTopic wird ausschließlich zum Empfangen von Nachrichten verwendet (also z.B. die Rückmeldung, ob eine Lampe an oder aus ist), das commandTopic wird ausschließlich zum Versand von Nachrichten verwendet (also z.B. der Befehl, die Lampe ein- oder auszuschalten).

openHAB ist ereignisorientiert. Im Fall eines Items gibt es zwei Ereignisse, von denen eines noch etwas spezifiziert werden kann.
Ereignis 1 heißt received command, es wurde ein Befehl empfangen. Dieses Ereignis löst default eine Kette von Abläufen aus, angefangen mit dem Loggen des Ereignisses über das Starten von Rules, welche den Trigger receivedCommand eingetragen haben bis zum Weiterreichen des Befehls an alle verknüpften Channel. Die zugehörigen Bindings kümmern sich dann um den Versand des Befehls an die konfigurierten Devices. Nachdem der Befehl versandt wurde, „errechnet“ openHAB den wahrscheinlichen Status des Items nach Ausführen des Befehls und setzt diesen Status schon mal. Dieses Verhalten kann man abschalten (und sollte es im Normalfall auch tun).
Ereignis 2 heißt received update, es wurde ein neuer Status empfangen. Hier gibt es noch den Sonderfall, dass sich durch dieses Ereignis der Status des Items ändert. Dann wird zusätzlich zu received update das Ereignis changed ausgelöst.
received update löst nur das Aktualisieren des Status des zugehörigen Items aus.