please be advised, the angle brackets indicate you have to completely replace them with your own names:
In your case, please replace “<broker>” with your own name-convention. I have mqttoh2 for example, so this would then read:
# Define your MQTT broker connections here for use in the MQTT Binding or MQTT
# Persistence bundles. Replace <broker> with an ID you choose.
#
# URL to the MQTT broker, e.g. tcp://localhost:1883 or ssl://localhost:8883
mqttoh2.url=tcp://192.168.1.17:1883
# Optional. Client id (max 23 chars) to use when connecting to the broker.
# If not provided a random default is generated.
mqttoh2.clientId=openhabian
<...>
Hint: the first line in your config lacks the “#”, perhaps it’s just not enough copy, but be sure, that one is commented also.
I’m not quite sure, if I catched, what you’re saying - but you have to adjust the Code (at least remove the angle brackets from <broker>.clientId=openhabian …?
please have also a look in the logs after you changed the config. It should read something like this:
ok, now I see!
yes, you’re absolutely right, the name of the broker in your mqtt.cfg is to be used everywher, in this case also in your items-configuration. Are you sure, mqttob2 is in your mqtt.cfg?
What you see in the console is more or less what you’d get with the mosquitto_sub I mentioned earlier.
Sorry then for my being confusing! in that case, you have to go back to your original item configuration.
Sorry, if this was not clear enough: the name you give your broker in mqtt.cfg is the ID you have to use in every other context for openHAB.
so, if your broker names broker in mqtt.cfg you have to use broker in .items
I have tried to follow your advice this is what I have now am I anywhere near being right thank you for you patience
# Define your MQTT broker connections here for use in the MQTT Binding or MQTT
# Persistence bundles. Replace <broker> with an ID you choose.
#
# URL to the MQTT broker, e.g. tcp://localhost:1883 or ssl://localhost:8883
mqttoh2.url=tcp://192.168.1.17:1883
# Optional. Client id (max 23 chars) to use when connecting to the broker.
# If not provided a random default is generated.
mqttoh2.clientId=openhabian
# Optional. True or false. If set to true, allows the use of clientId values
# up to 65535 characters long. Defaults to false.
# NOTE: clientId values longer than 23 characters may not be supported by all
# MQTT servers. Check the server documentation.
#<broker>.allowLongerClientIds=false
# Optional. User id to authenticate with the broker.
#<broker>.user=<user>
# Optional. Password to authenticate with the broker.
#<broker>.pwd=<password>
# Optional. Set the quality of service level for sending messages to this broker.
# Possible values are 0 (Deliver at most once),1 (Deliver at least once) or 2
# (Deliver exactly once). Defaults to 0.
#<broker>.qos=<qos>
# Optional. True or false. Defines if the broker should retain the messages sent to
# it. Defaults to false.
#<broker>.retain=<retain>
# Optional. True or false. Defines if messages are published asynchronously or
# synchronously. Defaults to true.
#<broker>.async=<async>
# Optional. Defines the last will and testament that is sent when this client goes offline
# Format: topic:message:qos:retained <br/>
yes, that sounds good! now you should have the connection to your broker - and the console of your sonoff WebGUI should see the messages you send from openHAB…
(the only thing I’m a bit confused about is, that you have set User and Password for Sonoff for MQTT - and not in your mqtt.cfg… But as I can see from the openhab.log your openHAB connects to the broker and so does the Sonoff in the console).
thank you I have it working you have been amazing thank you for your time one last question if I may
i am using the below code i have mqttob2:cmnd should the second one say mqttoh2:stat if you can understand what i am trying to say
yes, absolutely right. the sonoff sends the actual state in the stat topic. (sorry, for not seeing this the first time).
so this one should do the trick:
hint: don’t rely on looking at the BasicUI at the present. There’s a minor bug, it won’t autorefresh, so after pressing the hardware button on the sonoff please reload the UI - then you should see the correct state.
FYI I’m at very close to the same starting point (basic linking of tasmota’d sonoffs) and the non-refreshing of BasicUI was causing me to question whether I was coding it right; but an update I did yesterday seems to have rectified the autorefresh! (not sure which update exactly, one if the ones in openhab-config, possibly “latest stable”). My original openhabian image was only from a few days ago, so not sure what’s changed since then.
The “broker” bit did trip me up in several ways, I think as it was in the angled brackets I assumed it was some sort of dynamic link.
I still don’t understand how the icon (eg. lightbulb) is fed back a state, I do have a map etc. and it’s working but I don’t know why/how! ; ) I can see there’s “out” messages (>) and “in” listeners (<), but can’t figure it out, are both icon and toggle fed by the same data?
PS. You may want to check you have the following installed for your next progression:
installed JSONPATH and Transform addon in Openhab?
goto paperUI> Add-on> Transormations , install JSONPath Transformation and Map Transformation
The icon & On/Off slider is updated based upon the internal state - which is (by default) updated when you press the button in BasicUI, or when the Sonoff sends a message in to OH.
To make these reflect the actual state of the Sonoff device, you can add , autoupdate=false to the end of your item, using the example given in the post a couple above:
Thanks Garry, so the icon state and the switch state are implicitly linked?
I do have autoupdate=false added, as I figured for the tasmota’d sonoff relays it’s best to actually get confirmation back as to the state change rather than just assume it’s gone through correctly.
When listing multiple “in” MQTT stats/teles, does this just result in one displayed item (eg. textfield) updated with whatever the last message was from one of the list?
There are three incoming messages specified for the item? Does this just update the one textfield with whichever the last piece of received data was, eg. display status2, a tele comes in so replace with that…? I couldn’t find anything about such a setup in the items documentation, just trying to get my head wrapped around the various layouts.
Thanks
Optional! A collection of return messages by the Sonoff module
Recommendation: Define specific items for what you really need on a regular basis, use standalone MQTT client for troubleshooting
you understood correctly then. the *_Verbose items in ThomDietrich’s example function as stringbased target for all kinds of information. And you have to have some kind of rule-based logic on how to deal with that information.
It’s sufficient, if you just want to see in event.log, what’s coming from your device.
Frankly, I don’t think that’s the best way to do it, if you want to use the transported information afterwards… If you want to work with those information, you can always create specific items for each topic - so you can have simple JSON-transrormation per item, something like this:
in that case, you have to go back to your original item configuration.