Espeasy: MQTT sending to Openhab broken
Using the latest (10/03) firmware sending sensor values or publishing via rules (numbers) is broken in openhab
No changes in rules or sensors was done from September 03 release (working) to October 03 release (broken, possibly before this one).
Sending a dallas sensor results in an error in openhab:
2019-10-11 09:15:32.180 [WARN ] [ab.binding.mqtt.generic.ChannelState] - Incoming payload '0 ' not supported by type 'NumberValue'
There seems to be extra space/blank characters after the number that weren't present previously.
Again, this happens with sensors sending temperatures or rules publishing a number to openhab.
waspie
All 19 comments
Possible duplicates:
- #2660
- #2657
TD-er
on 14 Oct 2019
i've found similar issue
i suppose problem with template in src/_C005.ino:
case CPLUGIN_PROTOCOL_TEMPLATE:
{
event->String1 = F("%sysname%/#");
event->String2 = F("%sysname%/%tskname%/%valname%");
break;
}
this should be preceded with slash:
/%sysname%/#
/%sysname%/%tskname%/%valname%
without slash ESPEasy do not even try to send something to mosquitto, just silent, nothing in debug log either
if i'm right, can i correct it?
or maybe it's done for some reason, because old firmwares work well
i'm new to gitlab and don't know how things should be done right here
aleksey-ru52
on 16 Oct 2019
Nope, that's not related to this one (as far as I know)
Having a leading slash in MQTT topics is a bad idea.
It will create an extra (unneeded) layer in your topics.
If your current setup is based on having a leading slash, then please append one in your settings.
The code you quote is the template or in other words the "default", but nothing is stopping you to add a slash in front.
TD-er
on 16 Oct 2019
ok, understand
aleksey-ru52
on 16 Oct 2019
Hmm, you (now?) state it will not even send anything if the leading slash is omitted.
That does sound like a bug.
TD-er
on 16 Oct 2019
well, i have mosquitto for testing purposes on OpenWrt, it's a bit old release, i suppose
then i connect to it with this command:
mosquitto_sub -h 192.168.21.253 -v -t /#
it have slash in topic, i can't specify -t # because it generates error in mosquitto_sub
my openhub setup generates and listening channels with leading slash
how can i log/watch command send from ESPEasy? with log level "debug dev" in serial console i see nothing related to mosquitto
ohh... i'm trying to Publish through serial console - nothing happends, jast "command ok", and when i try to execute through web /tools i've got error in serial log:
[E][vfs_api.cpp:27] open(): TmplStd.htm does not start with /
[E][vfs_api.cpp:27] open(): esp.css does not start with /
[E][vfs_api.cpp:27] open(): esp.png does not start with /
2295891 : Command: publish[E][vfs_api.cpp:27] open(): TmplStd.htm does not start with /
and web console shows: "Command output: OK"
aleksey-ru52
on 16 Oct 2019
What is the exact command you gave in ESPeasy?
TD-er
on 16 Oct 2019
Publish 2,1 - silent in mosquitto and error in serial console if send from web
Publish /2,1 - Ok
aleksey-ru52
on 16 Oct 2019
well, a was wrong, sorry
mosquitto_sub -h 192.168.21.253 -v -t ESPEasy32/#
shows readings from thermo sensor
problem with my _own_ openhab setup, i will get it in mind from this time
aleksey-ru52
on 16 Oct 2019
mosquitto_sub -h 192.168.21.253 -v -t 2/#
serial and web Publish works well too
Publish 2,1 - generates error i mentioned above, but it sends message
from serial console this command executed without error
error generated with page reloading
aleksey-ru52
on 16 Oct 2019
Please test this against tomorrow's build, or try this test build
If it appears to be fixed, please close the issue.
TD-er
on 27 Oct 2019
Please test this against tomorrow's build, or try this test build
If it appears to be fixed, please close the issue.
This release (10/28) has resolved this issue for me
waspie
on 28 Oct 2019
I spoke too soon... I wonder if you'll see this if it is closed....
The sensors sending data are fine but the rules part is still broken.
Here's a rule:
on ping do
Publish /%sysname%/wd/ur,1
endon
The result in mosquitto is:
'
19-10-28 13:20:24.030 /utilityRoom/cmd Event,ping
2019-10-28 13:20:24.578 Publish /utilityRoom/wd/ur <----------------
'
It is sending the entire line including "Publish" ??????
waspie
on 28 Oct 2019
Hmm that's probably a bug I introduced.
What happens if you place them on separate lines like this:
on ping do
Publish /%sysname%/wd/ur,1
endon
It is on separate lines the message just didn't come out right
On Mon, Oct 28, 2019, 1:25 PM Gijs Noorlander notifications@github.com
wrote:
Hmm that's probably a bug I introduced.
What happens if you place them on separate lines like this:on ping do
Publish /%sysname%/wd/ur,1
endon—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/letscontrolit/ESPEasy/issues/2662?email_source=notifications&email_token=AIPOIRNJ5JYIIEX2BDG5AKLQQ4OB7A5CNFSM4JAR7I5KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECNW36Q#issuecomment-547057146,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AIPOIRJ3UVK6WTUENX6HAODQQ4OB7ANCNFSM4JAR7I5A
.
waspie
on 28 Oct 2019
Can you try this test build: ESPEasy_mega-20191028-21-PR_2698.zip
Please let me know if it does work and it would be great if you could do some more thorough testing so I can merge it for tomorrow's build.
TD-er
on 30 Oct 2019
I'll make sure the rules work right this time before reporting back.
waspie
on 30 Oct 2019
I send sensor data via MQTT and it is working.
I contact the node via MQTT (not import) and a rule catches it and send a reply and it is working
Sensors gather temperature data and a rule runs a formula on it and saves it to a dummy item (rule)
and that rule sends that dummy data via MQTT and it is working.
In all my use cases it is working.
waspie
on 30 Oct 2019
Thanks for testing and letting me know.
TD-er
on 30 Oct 2019
Related issues
tedenda
·
6Comments
wolverinevn
·
4Comments
ghtester
·
3Comments
Barracuda09
·
5Comments
TD-er
·
5Comments