Yes but not sure where the files are located for perusing. Have to read em through ssh.
The addons.cfg file will not be modified when you install a binging. As I understand it, any addons that you list in the .cfg file will be automatically installed the first time OpenHAB is run.
You can check whether the MQTT binding is installed in the paper UI.
@PointandClick it says it is.
I just ran this:
21:48:28] root@openHABianPi:/home/openhabian# mosquitto_sub -u openhab -P habopen -t diana/lights/cord1/# -v
diana/lights/cord1/LWT Offline
diana/lights/cord1 0
Nothing changes when I toggle the light through the Sonoff’s web gui.
However, when I toggle it through my openhab2 app on my phone, it switches between:
diana/lights/cord1 0
And
diana/lights/cord1 1
So OpenHAB is doing it’s part. When you toggle the switch from the UI it is publishing to the topic you have set in your item definition. Your map file is working too since you are getting 1 and 0 rather than ON and OFF.
My guess is that you have a mismatch in your topics between what you set up in your item and what your Sonoff is subscribed to. I’m not sure what firmware you are running on your Sonoff.
In your OP it appears that your Sonoff is configured for the topic “diana/lights/cord/power” but you have your item configured as “diana/lights/cord1”
A screenshot of your Sonoff config might be helpful.
You can find them in /var/log/openhab2 The event.log shows all item actions in OpenHab and the openhab.log will contain your warn/debug log entries.
Full topic on Sonoff
diana/lights/cord1
I had changed it a few days back.
In karaf console
log:display gives a bit of info.
What firmware are you running on your Sonoff? This sounds like a configuration issue to me, not an openhab issue. As your subscription test shows, OH is sending the command you told it to when you activate the switch from the UI. If the Sonoff is not responding, it is more than likely not the right command.
Tasmota
I’ll be going through the wiki with a fine toothed comb here in a minute.
From the wiki:
Switch LivingRoom_Light "Living Room Light" <light> (LR,gLight)
{ mqtt=">[broker:cmnd/sonoff-A00EEA/POWER:command:*:default],
<[broker:stat/sonoff-A00EEA/POWER:state:default]" }
I see ‘cmnd/’ at the beginning
So I think I need
Switch cord1 “Cord” {mqtt="<[mosquitto:stat/diana/lights/cord1:state:MAP(Sonoff_onoff.map)], >[mosquitto:cmnd/diana/lights/cord1:command:ON:1], >[mosquitto:cmnd/diana/lights/cord1:command:OFF:0]"}
So you are using Sonoff Tasmota. Since you are using a custom topic you can’t copy the examples as is.
I’ve never used Tasmota, but I will try to explain how I understand it works based on the wiki.
The cmnd and stat in the examples are what are called the prefix. You have your full topic hard coded to “diana/lights/cord1/power” so your sonoff isn’t looking for the prefix.
The “POWER” at the end of the example topic is an attribute of the sonoff. In this case the Power, or relay. You don’t need this in your topic definition.
My recommendation would be to change your topic back to the default.
%prefix%/%topic%/
This will allow you to use the examples nearly as is.
Switch cord1 “Cord” { mqtt=">[broker:cmnd/lights/POWER:command:*:default],
<[broker:stat/lights/POWER:state:default]" }
Personally, I would change your device “Topic” to something different than “lights” What they are calling “Topic” I would more accurately call a device identifier. Once you start adding multiple units, “lights” isn’t going to tell you which one you’re controlling. “Travalons-lamp” on the other hand gives you something descriptive so you know what you are controlling. You’re item definition would then be:
Switch cord1 “Cord” { mqtt=">[broker:cmnd/Travalons-lamp/POWER:command:*:default],
<[broker:stat/Travalons-lamp/POWER:state:default]" }
I find the documentation for Tasmota and the way things are handled to be somewhat confusing… but maybe that’s just my lack of sleep.
Once you get more comfortable with MQTT you can try to work with custom topics if you feel the need.
@PointandClick
Thank you. I just had an AHHHH moment. A light went on. (Unfortunately not the one I was shooting for) I just reset the Sonoff to defaults and was working on the topic before I read this. Your explanation of “Topic” gives me an idea. I went with lights to differentiate what I was going to use the switches for. I’ll take your advice and get em working with as many default settings as possible then go from there.
Glad things are starting to come together for you. Differentiating them by purpose is fine as long as you have some way to tell which is which once you have more than one. I actually do something similar with my plug in outlets in that I name them OL1, OL2… Then I can label them so I know which is which. If I ever want to use it for something different, I can just change the label in OH.
Like I said, I find some the Tasmota design decisions to be confusing and the documentation doesn’t always fully explain some things.
1 Like
flashing a 2nd at the moment. strange behavior. had to use Arduino IDE to flash the 1st one and PlatformIO for the 2nd.
So I’ve tried everything. Including defaults. All I can think of is a problem with the mqtt binding. I have tried to install, uninstall, install, uninstall through the paper ui who knows how many times. It shows installing and the spinning circle never stops. Unless I refresh the screen, then it shows installed. Its like this for all bindings. Then no things are discovered. I even tried
[sudo[23:12:56] root@openHABianPi:/home/openhabian# apt-get install openhab-addon-binding-mqtt Reading package lists... Done Building dependency tree
Reading state information... Done
E: Unable to locate package openhab-addon-binding-mqtt
So how do I know it is installed?
To check if a binding has been properly installed, you can use the openHAB console:
openhab> bundle:list -s |grep -i mqtt
202 | Active | 80 | 1.11.0.201707300110 | openHAB MQTT Binding | org.openhab.binding.mqtt
209 | Active | 80 | 1.11.0.201707300110 | openHAB MQTT Transport Bundle | org.openhab.io.transport.mqtt
Status should be “Active”
Sometimes, installing an addon from PaperUI gives you that never ending spinning circle. I usually browse to another section of PaperUI and then back to the addon page (give it a few secs to download the binding jar from the online repo and install it).
If this happens to all addons, check your openhab.log file for errors. Maybe the download is failing and/or there are file permission issues (bundles will be deployed in userdata/tmp)
For starters, try to avoid using the addons.cfg file (don’t define any bindings in there).
1 Like