I’ve done a full nmap scan and port 1883 is not open, so no matter what is sent to it, it wont play.
I have manage to get inside and its a ESP8266MOD
Has anyone relashed one of these ?
on what device?
If you are referring to the relay, of course it doesn’t have 1883 open because it’s not listening on port 1883. If you are referring to your broker, fix that first.
Once again, please use MQTT Explorer to publish a 1 to
/iot4/IOT4SH01RELAY_D34IDE/relay/set
and confirm if it activates the relay.
I’ve used both MQTT-Explorer and MQTT-FX to send a 1 to the relay,
watching at the same time capturing the packets with tcpdump amd analysing with wireshark
Nothing is sent to the relay, which uses a ESP8266MOD module
I’ve sent to /relay/set, /relay/0. relay/1 and just /relay plus the other topics listed that may accept an input.
I’ve included what he listed as the full chip ID to the hostname , only an additional “E” at the end, made no difference.
I’ve also edited a script to repeatedly send alternate 1 and 0 for 30 secs from MQTT-FX and watched the results on MQTT-FX and MQTT_Explorer and the published output is seen on each,
but are not going to the relay, the screenshot of wireshark shows this.
Richard
OK. If you’ve published a payload to all of those topic variations and (with wireshark) observed nothing being sent to the relay, that means the relay is not subscribed to any of those topics.
Upon startup, the relay connects to the broker and subscribes to one or more topics. When MQTT Explorer publishes a payload to the correct topic, the broker will forwarded it to the relay.
We know the relay is connected to the broker because MQTT Explorer is showing all the topics the relay publishes to. The problem so far is we don’t know the name of the topic the relay subscribes to (i.e. the topic it uses for receiving commands). All payloads you’ve published, to a variety of topics, don’t get to the relay.
I believe now is the time for you to contact the manufacturer and request detailed information about the relay. Ask for the name of the topic the relay uses to receive commands.
Why do you keep making this so complicated by using tcpdump, nmap, wireshark, etc.and giving us a data dump?
please, just for now open mqqtfx, subscribe to all topics and turn on and off the relay one time using the web app of the device, then do the same by publishing a 1 & 0 to the relay topic from the HA services page in dev tools. tell us if the relay was or was not turned on/off by using each method.
Then post a screen shot of the results that looks substantially like this:
I believe turning the relay on/off, using its web-interface, will only cause it to publish to the topics that we can already see in MQTT Explorer. It’s not likely to cause the relay to publish a payload to its own command topic. That’s the topic we need to discover and, given that Richard has tried several possibilities without success, I think it’s time to contact the manufacturer.
The manufacturer’s documentation indicates /iot4/IOT4SH01RELAY_D34IDE/relay/0 is the command topic but, based on Richard’s results, it doesn’t work (i.e. the broker does not forward a payload to that topic).
I have already contacted him, but no answer, no phone number on his site.
no postal address either.
So a waiting game, i’ll give it a few days , and if no response look into reprogramming
the ESP8266,
thanks for your time
Richard
Finity, I have done that and used the fountain script modified for each one in turn, and no response from the relay.
tcpdump and wireshark are useful as it shows it data is being sent to the relay, but its not.
PITA
Sounds like a good plan.
While waiting for the manufacturer to reply, you may wish to spend some time comparing the features of firmware available for the ESP8266. You have several popular options to choose from:
- Tasmota
- Espurna
- ESPeasy
- ESPHome
Thanks I’ll look at tasmota, as I have a couple of sonoff switches that have been flashed
with Tasmota
Got it working,
but there is something very strange on hown it must be entered.
/iot4/IOT4SH01RELAY_D341DE/relay/0/set
is what works
BUT NOT if you type it in the publish topic in MQTT-Explorer
however, if you type in “/iot4/” and then copy and paste from the LH pane and then type in
“/relay/0/set”
it accepts the payload
goint to HA gui
from the developer tools
type in “/iot4/IOT4SH01RELAY_D341DE/relay/0/set” and send a payload
and it does zilch !!!
copy and paste from the topic in mqtt-exp, and it works
exactly the same thing happens in configuration.yaml
Whats even more strange is I typed back in the original hostname on the device after I had renamed it “PIG”.
So what was entered fom this laptop should be the same; so the character set should be the
same.
I only found it by accident as I was too lazy to retype the line in mqtt-exp, after it failed the first time, and copied and pasted .
As it a linux OS here , I found that copy and paste doesn’t work in and from mqtt-expl.
but as on all linux OS’s if you just hightlight text, you can drop it where ever by using both L&R mouse buttons at the same time.
I dont understand the process, there should not be a hidden characters , or special ones.
But at least now it works, 
As it happens from mqtt-exp, it rules out HA, so it looks like a mosqitto/mqtt gotcha
thanks for the help on this one
Richard
This is a very confusing description but I think I understand what you mean. You are saying that you copy/pasted the string IOT4SH01RELAY_D341DE from MQTT Explorer’s left hand pane into the right hand pane’s publish section in order to create the topic /iot4/IOT4SH01RELAY_D341DE/relay/0/set. Only by doing that were you able to create a topic that the relay could use for receiving payloads.
In other words, you believe that there is some kind of ‘special character’ in that string that you were unable to duplicate when you typed the string manually.
Frankly, I find that explanation to be difficult to believe. I suggest you paste the string into a text editor that can display special characters or, even better, as hex codes. That will prove/disprove your theory that it contains something ‘hidden’ or ‘special’.
The other reason why your theory is flawed is because in this post you used mosquitto_sub to subscribe to /iot4/IOT4SH01RELAY_D341DE/# in order to display all its sub-topics. The fact you manually typed that topic’s string, in order to subscribe to it, indicates there’s no ‘hidden’ or ‘special’ characters in it.
FWIW, the MQTT 3.1.1 Specification indicates all characters must be UTF-8.
Hurray it works but your explanation for why it works is unlikely to be the true reason.
2 Likes
I agree … there would be no sensible reason to implement such a thing and many reasons not too.
Maybe ‘raw’ data wasn’t selected ? I would have thought the inbuilt copy/paste buttons would have worked and also just click selecting the topic… but I don’t use the Linux version… maybe post it to Thomas’ Github as a bug if they truly don’t.
Anyway what matters is it’s working now…
Hi Xappo
raw data was selected, It has to be something strange with mosquitto, but it could be on mqtt-explorer.
but if mqtt-explorer, why the same effect on HA.
I should have tried on mqtt-fx, but all I did there was to alter the script after it was working to rapidly togle the state of the relay for 30 secs, which it did.
And just to add to the confusion
mosquitto_pub -p 1883 -t /iot4/IOT4SH01RELAY_D341DE/relay/0/set -m "1"
from CLI works
The main thing is that its now working
Richard
So what was suggested several dozen posts ago, and was reported to not work, now magically works?
Sure.
3 Likes
what is “PEBKAC”? I’ve not seen that one before.
Problem Exists Between Keyboard And Chair
That’s hilarious! I’ll definitely keep that one.
I’m surprised that wiki doesn’t have PICNIC, Problem in chair not in computer.
EDIT: Nevermind, I just missed it.