MQTT Pub -Sub failure. It's me

Mine is setup as command as well. The one thing I do (not sure if necessary or not) is separate my inbound from outbound topics (I add a /set at the end of my inbound for items that are controlled by OH), but you could add a /state for your outbound. I assume there is a loop trap built into the mqtt binding but wanted to make sure that I didn’t create a loop situation.

could you please give me an example when you have a chance?

Sure, here’s mine for a zwave device controlled by OH:

Dimmer  Light_GF_Dining_Main  "Dining Main Light"  <Dimmablelight>  (Dining_Lights, GF_Dining)  {channel="zwave:device:54545887:node3:switch_dimmer",  mqtt="<[mqttloc:home/diningRoom/diningMainLight/set:command:default],>[mqttloc:home/diningRoom/diningMainLight:state:*:default]"}

You assume incorrectly. There is no loop trap and it is very easy to get stuck into such a loop unless you do, as you suggest, and separate the incoming and outgoing topics. I’ll often even separate the inbound and outbound into separate Items and use a Proxy Item and Rules to represent the device.

There is also an autoupdate=false one can add to the bindings that will keep the incoming updates from triggering the outgoing bindings which can prevent the loops.

Comparing the two, I’m wondering if my commands should be changed to

‘:default’ and ‘*:default’ from
’ON:1’ and ‘OFF:0’

Switch cord1 “Cord” {mqtt="<[mosquitto:diana/lights/cord1:state:default], >[mosquitto:diana/lights/cord1:command:ON:1], >[mosquitto:diana/lights/cord1:command:OFF:0]"}

Dimmer Light_GF_Dining_Main “Dining Main Light” (Dining_Lights, GF_Dining) {channel=“zwave:device:54545887:node3:switch_dimmer”, mqtt="<[mqttloc:home/diningRoom/diningMainLight/set:command:default],>[mqttloc:home/diningRoom/diningMainLight:state:*:default]"}

It depends on what is needed on the other end to represent an on/off event. Yours reflects a mapping of ON from OH to 1 to your device and OFF from OH to 0 to your device.

I’d instead play with separating the inbound from outbound topics to see if you are stuck in a bootloop.

Also, did you ever get a debug log file to see what the communication back and forth is?

I’m at work right now and can’t get the debug. But you answered another question I had. I don’t have a mapping file configured.

Would this work in the transformations folder?

Binary.map
key=value
1=ON
0=OFF
ON=1
OFF=0

You don’t have to since you did the mapping in your channel statement. But the other option is a mapping file, just make sure you install the correct binding and reference it in your channel statement.

1 Like

Its just a Sonoff basic. On/Off

Based on your item definition above you are sending it a “1” when cord1 is switched On and a “0” when cord1 is switched Off. Now realize that on the state check channel you will be getting back a 1 or 0 not an “On” or “Off” so if you need it in On / Off format then you will either have to setup a proxy item and a rule like @rlkoshak suggested or do a transformation (easiest way for me is a map file since I’m not a coder by nature so haven’t dug into how to use Regex or some other inline transformation). For that situation on your inbound you would replace “:state:default” with “:state:MAP(Binary.map)” (no quotes and I used the map file name you provided above)

Thank you rgerrans. I was reading another thread (Mosquitto errors) and learned a thing or two that combined with your help may solve the problem sooner than later.
Crud! Now I want to leave work early. OK to be honest, I always want to leave work early.

Do I need to give the file path to the MAP file?

Not as long as it’s in the transformation directory and you installed the mapping transformation binding.

Home Automation = Major Procrastination :wink: I’ve spent way too many hours when I should have been doing other stuff. My wife doesn’t accept it as a legitimate hobby…

Good luck!!

1 Like

So it should look like this?

Switch cord1 “Cord” {mqtt="<[mosquitto:diana/lights/cord1:state:MAP(Sonoff_onoff)], >[mosquitto:diana/lights/cord1:command:ON:1], >[mosquitto:diana/lights/cord1:command:OFF:0]"}

sonoff_onoff.map is how I named the file.
It looks like this

1= ON
0= OFF
OFF=0
ON=1

@sihui @rgerrans Thanks for the debug command. Its now set up and I have my whole setup in a box at work ( just plug it in) so I can work on it.

I believe you need to add the .map file extension to your item definition.

Like sonoff_onoff.map?

And how to read the debug logs from a tablet. I don’t have home designer available.

Yes

1 Like

If I have bindings installed would they show up in the add-ons.cfg?

I have this and it seems like the default file with nothing installed.

[21:28:43] openhabian@openHABianPi:/etc/openhab2/services$ cat addons.cfg
# The installation package of this openHAB instance
# Note: This is only regarded at the VERY FIRST START of openHAB
# Note: If you want to specify your add-ons yourself through entries below, set the package to "minimal"
# as otherwise your definition might be in conflict with what the installation package defines.
#
# Optional. If not set, the dashboard (https://<yourserver>:8080/) will ask you to choose a package.
#
# Valid options:
#   - minimal  : Installation only with dashboard, but no UIs or other add-ons. Use this for custom setups.
#   - simple   : Setup for using openHAB purely through UIs - you need to expect MANY constraints in functionality!
#   - standard : Default setup for normal users, best for textual setup
#   - expert   : Setup for expert users, especially for people migrating from openHAB 1.x
#   - demo     : A demo setup which includes UIs, a few bindings, config files etc.
#
# See http://docs.openhab.org/configuration/packages.html for a detailed explanation of these packages.
#
#package = minimal

# Access Remote Add-on Repository
# Defines whether the remote openHAB add-on repository should be used for browsing and installing add-ons.
# This not only makes latest snapshots of add-ons available, it is also required for the installation of
# any legacy 1.x add-on. (default is true)
#
#remote = true

# Include legacy 1.x bindings. If set to true, it also allows the installation of 1.x bindings for which there is
# already a 2.x version available (requires remote repo access, see above). (default is false)
#
#legacy = true

# A comma-separated list of bindings to install (e.g. "sonos,knx,zwave")
#binding =

# A comma-separated list of UIs to install (e.g. "basic,paper")
#ui =

# A comma-separated list of persistence services to install (e.g. "rrd4j,jpa")
#persistence =

# A comma-separated list of actions to install (e.g. "mail,pushover")
#action =

# A comma-separated list of transformation services to install (e.g. "map,jsonpath")
#transformation =

# A comma-separated list of voice services to install (e.g. "marytts,freetts")
#voice =

# A comma-separated list of miscellaneous services to install (e.g. "myopenhab")
#misc =
[21:28:53] openhabian@openHABianPi:/etc/openhab2/services$

I don’t believe they do anymore if you install them through PaperUi. I’m not home where I can double check. Did you get debug turned on for mqtt?