I have an ESP12 board with a pair of DS18B20 temperature sensors on GPIO2 - the MQTT input node returns an object including names DS18B20-1 and DS18B20-2 which I cannot seem to extract to get values out.
I noted on the web someone published a rule, slightly modified here but you get the idea.
Rule1 on DS18B20-1#temperature do publish stat/mosfet/DS18B20a %value% endon on DS18B20-2#temperature do publish stat/mosfet/DS18B20b %value% endon
It works - I can extract DS18B20a and DS18B20b and get their temperature values but the MQTT input node insists on pulling in data every second (no idea why) so I end up having to use rate limiting (delay node).
Any ideas as to a better way? I only need to read the temperature once a minute at most.. standard TELE response rates would be fine.
No it doesn't. The MQTT In node does not pull data, it gets pushed data from the mqtt broker. If the MQTT In node is giving you data every second then the publisher if publishing data at that rate, so you should fix it at that end. If you do not believe this is the case then install MQTT Explorer to check.
In addition, MQTT Explorer will let you see what else is being published by the device, which may be useful to you.
It looks as if you might be using ESPeasy firmware on the ESP12.
If so, you can specify how often to send readings by setting a value for 'Interval' in the 'Devices tab'...
This method doesn't use any rules, just sends the reading(s) via MQTT controller every 60-sec.
Or perhaps it's Tasmota, which has very similar Rules syntax.
On the OP's blog there is what appears to be some background to this question.
You seem to be using Rules (inappropriately) to retrieve sensor data because your sensor names contain a hyphen:
Well, NO. You can’t extract “DS18B20-1” because it gets treated like an expression – and you can’t put quotes around that either.
Have you tried square bracket notation and quotes?
Nope – I’m using a fully updated Tasmota.
No. Trying that right now...
RIGHT - and for anyone falling into the same trap.... in the case of my "mosfet" device the MQTT in needs to be:
returning a PARSED JSON OBJECT
The FUNCTION to read the first sensor is:
Thank you jbudd. Perfect.
To get that response I'm injecting topic:
and payload 10
every 30 seconds
I could have waited for TELE I guess but this'll do for now.
@scargill SetOption64 can be used to switch from default.legacy
_ instead of
- in JSON keys
The default to use
- is an unfortunate choice but it was decided not to break what was existing and offer the ability to change it by choice.
Thanks - the brackets-quotes solution works a treat. I am however using a cmnd to get a stat reading back - and though it works prefectly and I need to do it that way, I'm wondering what I was doing wrong with my TELE MQTT input as after a few minutes I wasn't seeing anything... I thought tele/mosfet/sensor would do it - but nothing.
What topics is MQTT Explorer showing?
Didnt try - didnt need to - see solutions above...
You said you wanted to know why you were not seeing the TELE messages. Explorer should show you the topic.
Oh I seee - yes I'll look ta... though in the end I need more control than the tele message will give. Got to turn the pump on if it's not cold, wait a bit to find out if the hot pipe is warmer than the cold pipe, then keep the pump on if it is.... until it isn't
Ok, I'm lost - I have MQTT Explorer running in Windows - and I juat had it send tele/mosfet/TelePeriod with a value of 30
The program is subscribed to tele/mosfet
yet looking at what's happening I can see my command was accepted but no tele events are recorded.. It is now 00:42 on 5th,
TelePeriod is a command.
EIther enter it directly in the web console or via MQTT: topic cmnd/<blah/blah>/TelePeriod and payload 30
Note commands are not case sensitive. teleperiod works too.
Edit: (Not relevant, scrubbed)
Yes I just realised it was a command cmnd and ignore the time comment - the time setting was miles out.....
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.