Generic MQTT switch is not posting to topic

  • Platform information:
    • Hardware: VirtualBox 4gb ram 4x cpu
    • OS: ubuntu 20.04
    • Java Runtime Environment: 1.8.0_265 Zulu
    • openHAB version: 2.5.7-1
  • Issue of the topic: I have programmed a ESP8266 D1 mini with espeasy mega-20200812 and exposed the onboard led gpio2 along with rssi. I am able to read the rssi just fine but unable to write out to the onboard led. My Thing is a generic MQTT thing and my item is configured as a switch. I have the MQTT State topic set to “ESP_Easy/LED/LED” and the MQTT Command Topic set to “ESP_Easy/gpio/2”. I have tested with MQTT explorer and found that if i post a message to this command topic with the value of 1 or 0 it toggles the led as expected minus in the reverse as 1=off and 0=on it seems. However when i toggle the switch in Paper UI control i dont see anything getting sent to MQTT. I have enabled all logging all in the mosquitto config and can see the esp sending state but i never see openHab posting the command. I am able to see when i send a message with mqtt explorer. Looking at the openhab2 log i also see the log entries that state changed from so openhab is acting like it did something but no correlating log in mosquitto.
  • Please post configurations (if applicable):
    All items where added through paperUI so i have done no manual config files.
  • If logs where generated please post these here using code fences:
    This is all i am seeing in the openhab log:

    2020-08-23 14:16:17.491 [vent.ItemStateChangedEvent] - Received event of type ‘ItemStateChangedEvent’ under the topic ‘smarthome/items/ESP_Easy_LED/statechanged’ with payload: ‘{“type”:“OnOff”,“value”:“ON”,“oldType”:“OnOff”,“oldValue”:“OFF”}’
    2020-08-23 14:16:17.492 [vent.ItemStateChangedEvent] - ESP_Easy_LED changed from OFF to ON


Based on researching of this issue i have a feeling im going to have to have a transformation or something to correct the reverse logic and to get it to send in single bit value but right now im not even seeing a entry in mosquitto. Note when i started this i did enable the built in broker but after some research found it was recommended to use mosquitto instead so i uninstalled and and installed mosquitto. Best i can tell i do belive the built in broker is not running as mosquitto run on the same port and mosquitto wouldnt be able to start if the port was already in use.

There should be an option in your Thing configuration to force what ON and OFF states send over MQTT. Add your 1 and 0 as appropriate.

But just to be certain: are you saying that, when trying to send something from openHAB, even MQTT Explorer doesn’t show it?

Correct, i also enabled all logs on the mosquitto and it also does not see any events logged when toggling the switch inside of open hab. Im not even to the point of figuring out how to format the message properly as currently there is no message being sent to format.

As for your first comment yes i seen other post being able to specify a on and off state but those boxes are not there. instead i just have this.

I have tried changing that to 0 and 1 but still no message being sent to mqtt.

Note openhab is able to see state change of the led when i use mqtt explorer to change the esp led state manually but for whatever reason openhab is not sending any messages to mqtt when you toggle the switch in openhab control.

How have you proven that openHAB can see the state change?

In general, MQTT setup in openHAB usually consists of:

  1. Definition of a connection to an MQTT broker (Mosquitto), often called a bridge.
  2. Definition of a Thing, which references the bridge previously defined. This Thing is for the whole device.
  3. Definition of a Channel within the Thing, which can be quite a few things(!), but for you will be a switch. This channel subscribes to the relevant MQTT topics, and does any necessary transformations.
  4. Definition of an Item, which in this case will be a switch Item, and will refer to the switch Channel previously created.
  5. Definition of a switch widget in a sitemap, which will refer to the Item just created, and which you can access from the BasicUI or the mobile apps.

So: Bridge -> Thing -> Channel -> Item -> Sitemap, each referring to the the part before it.

Which of the above have you already configured?

Bear in mind that PaperUI is an administrative UI, and isn’t meant for controlling your devices!

When i force state change by posting into mqtt against the “ESP_Easy/gpio/2” topic i can see when running a tail -f on the events.log of openhab a entry reflecting that the state was changed.

All 1-4 i have configured. Yes i understand PaperUI is just a front end to openhab and is just making calls to the openhab java api’s to do the actual work.


As for sitemap i am not using that just yet. I am utilizing the control inside of paperui to toggle it on and off to test.
This works with all of my zwave devices so i assume it should work the same here. I do see as i mentioned log entries in openhab2 that openhab seems to think changed state but again no messages being sent to broker.

Note i also added the availability topic to my ESP_Easy thing which is also reflecting online.

If you want to send a payload on your channel commandTopic, you will need to command your Item, not update its state.
Check in your events.log to see what events are going on with your Item.

Agreed, as stated previously i have been watching the events.log. The events.log when you toggle the switch indicates it did change the state as indicated by the above screenshot however the logs in mosquitto show no entries that it ever received a message to do the same. its like there is a broken link somewhere from the item to the broker. I can send a command using mqtt explorer and the device responds, i see a message get posted, and the listener part of the mqtt channel updates per the events.log so the listener works fine. Its only the command topic it is not posting to.

For the MQTT channel to send on commandTopic, the linked openHAB Item has to receive a command. This is not at all the same as a state change. There might well be one, but you’ve not mentioned it, or shown it, and what happens with the Item state is irrelevant to sending out MQTT.

On the subject of links, we haven’t yet proven that exists. If you display your ESP_Easy Thing, and its channels, and click the blue blob for LED channel, what Items are linked? I would also edit the link to make sure you haven’t accidentally selected follow profile or something.

Signal is reading just fine. LED is reading fine. Only having issues with LED.
Here is the channel for LED.

Here is the LED Item.

When i toggle the swithch in paperui control here is a tail -f | grep ESP_Easy_LED on /var/log/openhab2/events.log

andrew@OpenHab-Home:/var/log/openhab2$ tail -f events.log | grep ESP_Easy_LED
2020-08-23 17:14:46.961 [ome.event.ItemCommandEvent] - Received event of type ‘ItemCommandEvent’ under the topic ‘smarthome/items/ESP_Easy_LED/command’ with payload: ‘{“type”:“OnOff”,“value”:“ON”}’
2020-08-23 17:14:46.962 [ome.event.ItemCommandEvent] - Item ‘ESP_Easy_LED’ received command ON
2020-08-23 17:14:46.963 [nt.ItemStatePredictedEvent] - Received event of type ‘ItemStatePredictedEvent’ under the topic ‘smarthome/items/ESP_Easy_LED/statepredicted’ with payload: ‘{“predictedType”:“OnOff”,“predictedValue”:“ON”,“isConfirmation”:false}’
2020-08-23 17:14:46.964 [nt.ItemStatePredictedEvent] - ESP_Easy_LED predicted to become ON
2020-08-23 17:14:46.988 [vent.ItemStateChangedEvent] - Received event of type ‘ItemStateChangedEvent’ under the topic ‘smarthome/items/ESP_Easy_LED/statechanged’ with payload: ‘{“type”:“OnOff”,“value”:“ON”,“oldType”:“OnOff”,“oldValue”:“OFF”}’
2020-08-23 17:14:46.990 [vent.ItemStateChangedEvent] - ESP_Easy_LED changed from OFF to ON

And here is the output logs when toggling the device in paper ui running a tail -f | grep ESP_Easy_LED on openhab.log

@OpenHab-Home:/var/log/openhab2$ tail -f openhab.log | grep ESP_Easy_LED
2020-08-23 17:09:57.486 [DEBUG] [org.eclipse.jetty.server.HttpChannel] - REQUEST for // on HttpChannelOverHttp@24171eb0{r=1,c=false,c=false/false,a=IDLE,uri=//,age=0}
POST // HTTP/1.1
2020-08-23 17:09:57.487 [DEBUG] [.eclipse.jetty.server.HttpConnection] - HttpConnection@1ff8d3b4::SocketChannelEndPoint@17a6e4b7{/<->/,OPEN,fill=-,flush=-,to=31/30000}{io=0/0,kio=0,kro=1}->HttpConnection@1ff8d3b4[p=HttpParser{s=CONTENT,0 of 3},g=HttpGenerator@3fdb0fa0{s=START}]=>HttpChannelOverHttp@24171eb0{r=1,c=false,c=false/false,a=IDLE,uri=//,age=1} parsed true HttpParser{s=CONTENT,0 of 3}
2020-08-23 17:09:57.488 [DEBUG] [org.eclipse.jetty.server.HttpChannel] - HttpChannelOverHttp@24171eb0{r=1,c=false,c=false/false,a=IDLE,uri=//,age=2} handle //
2020-08-23 17:09:57.489 [DEBUG] [org.eclipse.jetty.server.HttpChannel] - HttpChannelOverHttp@24171eb0{r=1,c=false,c=false/false,a=DISPATCHED,uri=//,age=3} action DISPATCH
2020-08-23 17:09:57.490 [DEBUG] [org.eclipse.jetty.server.Server ] - REQUEST POST /rest/items/ESP_Easy_LED on HttpChannelOverHttp@24171eb0{r=1,c=false,c=false/false,a=DISPATCHED,uri=//,age=4}
2020-08-23 17:09:57.491 [DEBUG] [ax.web.service.spi.model.ServerModel] - Matching [/rest/items/ESP_Easy_LED]…
2020-08-23 17:09:57.492 [DEBUG] [ax.web.service.spi.model.ServerModel] - Path [/rest/items/ESP_Easy_LED] matched to {pattern=/rest/.,model=ServletModel{id=org.ops4j.pax.web.service.spi.model.ServletModel-5,name=org.ops4j.pax.web.service.spi.model.ServletModel-5,urlPatterns=[/rest/],alias=/rest,servlet=com.eclipsesource.jaxrs.publisher.internal.ServletContainerBridge@1c849e0a,initParams={},context=ContextModel{id=org.ops4j.pax.web.service.spi.model.ContextModel-4,name=,httpContext=DefaultHttpContext [bundle=com.eclipsesource.jaxrs.publisher_5.3.1.201602281253 [19], contextID=default],contextParams={},virtualHosts={},connectors={}}}}
2020-08-23 17:09:57.492 [DEBUG] [.jetty.server.handler.ContextHandler] - scope null||/rest/items/ESP_Easy_LED @ HttpServiceContext{httpContext=DefaultHttpContext [bundle=com.eclipsesource.jaxrs.publisher_5.3.1.201602281253 [19], contextID=default]}
2020-08-23 17:09:57.494 [DEBUG] [.jetty.server.handler.ContextHandler] - context=||/rest/items/ESP_Easy_LED @ HttpServiceContext{httpContext=DefaultHttpContext [bundle=com.eclipsesource.jaxrs.publisher_5.3.1.201602281253 [19], contextID=default]}
2020-08-23 17:09:57.496 [DEBUG] [eclipse.jetty.servlet.ServletHandler] - servlet |/rest|/items/ESP_Easy_LED -> org.ops4j.pax.web.service.spi.model.ServletModel-5@378be0fd==com.eclipsesource.jaxrs.publisher.internal.ServletContainerBridge,jsp=null,order=-1,inst=true,async=true
2020-08-23 17:09:57.497 [DEBUG] [ce.jetty.internal.HttpServiceContext] - Handling request for [/rest/items/ESP_Easy_LED] using http context [DefaultHttpContext [bundle=com.eclipsesource.jaxrs.publisher_5.3.1.201602281253 [19], contextID=default]]
2020-08-23 17:09:57.502 [DEBUG] [.eclipse.jetty.server.HttpConnection] - HttpConnection@1ff8d3b4::SocketChannelEndPoint@17a6e4b7{/<->/,OPEN,fill=-,flush=-,to=46/30000}{io=0/0,kio=0,kro=1}->HttpConnection@1ff8d3b4[p=HttpParser{s=CONTENT,0 of 3},g=HttpGenerator@3fdb0fa0{s=START}]=>HttpChannelOverHttp@24171eb0{r=1,c=false,c=false/false,a=DISPATCHED,uri=//,age=16} parse HeapByteBuffer@d674790[p=565,l=568,c=8192,r=3]={POST /rest/items/…db:adblk_no\r\n\r\n<<>>TF06PVBSMXV3A|159…d":true,“verify} {}
2020-08-23 17:09:57.505 [DEBUG] [org.eclipse.jetty.server.HttpChannel] - HttpChannelOverHttp@24171eb0{r=1,c=false,c=false/false,a=DISPATCHED,uri=//,age=19} onContent Content@7070e2c9{HeapByteBufferR@750138aa[p=565,l=568,c=8192,r=3]={POST /rest/items/…db:adblk_no\r\n\r\n<<>>TF06PVBSMXV3A|159…d”:true,"verify}}
2020-08-23 17:09:57.511 [DEBUG] [org.eclipse.jetty.server.HttpChannel] - HttpChannelOverHttp@24171eb0{r=1,c=false,c=false/false,a=DISPATCHED,uri=//,age=25} onContentComplete
2020-08-23 17:09:57.513 [DEBUG] [org.eclipse.jetty.server.HttpChannel] - HttpChannelOverHttp@24171eb0{r=1,c=false,c=false/false,a=DISPATCHED,uri=//,age=27} onRequestComplete
2020-08-23 17:09:57.517 [DEBUG] [.eclipse.jetty.server.HttpConnection] - HttpConnection@1ff8d3b4::SocketChannelEndPoint@17a6e4b7{/<->/,OPEN,fill=-,flush=-,to=61/30000}{io=0/0,kio=0,kro=1}->HttpConnection@1ff8d3b4[p=HttpParser{s=END,3 of 3},g=HttpGenerator@3fdb0fa0{s=START}]=>HttpChannelOverHttp@24171eb0{r=1,c=false,c=false/false,a=DISPATCHED,uri=//,age=31} parsed false HttpParser{s=END,3 of 3}
2020-08-23 17:09:57.520 [DEBUG] [.eclipse.jetty.server.HttpConnection] - releaseRequestBuffer HttpConnection@1ff8d3b4::SocketChannelEndPoint@17a6e4b7{/<->/,OPEN,fill=-,flush=-,to=65/30000}{io=0/0,kio=0,kro=1}->HttpConnection@1ff8d3b4[p=HttpParser{s=END,3 of 3},g=HttpGenerator@3fdb0fa0{s=START}]=>HttpChannelOverHttp@24171eb0{r=1,c=false,c=false/false,a=DISPATCHED,uri=//,age=34}
2020-08-23 17:09:57.524 [DEBUG] [rest.core.internal.item.ItemResource] - Received HTTP POST request at ‘items/ESP_Easy_LED’ with value ‘OFF’.
2020-08-23 17:09:57.527 [TRACE] [] - inspect event: org.osgi.service.event.Event [topic=smarthome] {topic=smarthome/items/ESP_Easy_LED/command, type=ItemCommandEvent, payload={“type”:“OnOff”,“value”:“OFF”}, timestamp=1598220597526}
2020-08-23 17:09:57.531 [TRACE] [ore.thing.internal.AutoUpdateManager] - Optimistically updating item ‘ESP_Easy_LED’
2020-08-23 17:09:57.534 [DEBUG] [org.eclipse.jetty.server.Server ] - handled=true async=false committed=false on HttpChannelOverHttp@24171eb0{r=1,c=false,c=false/false,a=DISPATCHED,uri=//,age=47}
2020-08-23 17:09:57.535 [DEBUG] [org.eclipse.jetty.server.HttpChannel] - HttpChannelOverHttp@24171eb0{r=1,c=false,c=false/false,a=COMPLETING,uri=//,age=49} action COMPLETE
2020-08-23 17:09:57.536 [DEBUG] [org.eclipse.jetty.server.HttpChannel] - COMMIT for /rest/items/ESP_Easy_LED on HttpChannelOverHttp@24171eb0{r=1,c=true,c=false/false,a=COMPLETING,uri=//,age=50}
2020-08-23 17:09:57.541 [TRACE] [] - inspect event: org.osgi.service.event.Event [topic=smarthome] {topic=smarthome/items/ESP_Easy_LED/statepredicted, type=ItemStatePredictedEvent, payload={“predictedType”:“OnOff”,“predictedValue”:“OFF”,“isConfirmation”:false}, timestamp=1598220597534}
2020-08-23 17:09:57.545 [DEBUG] [] - flushed 97 SocketChannelEndPoint@17a6e4b7{/<->/,OPEN,fill=-,flush=W,to=89/30000}{io=0/0,kio=0,kro=1}->HttpConnection@1ff8d3b4[p=HttpParser{s=END,3 of 3},g=HttpGenerator@3fdb0fa0{s=COMPLETING}]=>HttpChannelOverHttp@24171eb0{r=1,c=true,c=false/false,a=COMPLETING,uri=//,age=59}
2020-08-23 17:09:57.546 [TRACE] [] - inspect event: org.osgi.service.event.Event [topic=smarthome] {topic=smarthome/items/ESP_Easy_LED/state, source=org.eclipse.smarthome.core.autoupdate.optimistic, type=ItemStateEvent, payload={“type”:“OnOff”,“value”:“OFF”}, timestamp=1598220597534}
2020-08-23 17:09:57.549 [DEBUG] [org.eclipse.jetty.server.HttpChannel] - COMPLETE for /rest/items/ESP_Easy_LED written=0
2020-08-23 17:09:57.568 [TRACE] [] - inspect event: org.osgi.service.event.Event [topic=smarthome] {topic=smarthome/items/ESP_Easy_LED/statechanged, type=ItemStateChangedEvent, payload={“type”:“OnOff”,“value”:“OFF”,“oldType”:“OnOff”,“oldValue”:“ON”}, timestamp=1598220597566}
2020-08-23 17:09:57.571 [DEBUG] [nternal.profiles.ProfileCallbackImpl] - Delegating command ‘OFF’ for item ‘ESP_Easy_LED’ to handler for channel ‘mqtt:topic:d1f8785b:LED’
2020-08-23 17:09:57.628 [DEBUG] [nternal.profiles.ProfileCallbackImpl] - Delegating update ‘OFF’ for item ‘ESP_Easy_LED’ to handler for channel ‘mqtt:topic:d1f8785b:LED’

Does this help and if not what specifically can i share that will help?

Ok before posting that to try to make sure i had a clean setup i completely deleted the item and started from scratch. Now when i toggle the item in paperui control i see it posting to the proper topic but it is posting ON and OFF not 1 and 0 so now i need to figure out how to transform what is sent.

I am guessing that i just created the channel incorrectly as i now have a custom on/open value and custom off/closed value. It is now working. Now to translate this to a garage controller.

Thank you everyone for your help!