Smooth node question re objects

Guys,

I have a tasmota feeding in multiple temperature values from DS18B20.

In order i am

Converting JSON to JS Object
Splitting into what i am interested in
Switching to retrieve the different values

Now - i want to feed the temperatures into a Smooth node - this node says that is only accepts numbers - BUT does that mean it will extract a number from the object given the path or can it only accept "simple" raw numbers (i.e. i need to split and switch again ?) i have a lot of these to do and the extra steps would make the flows a little ugly(ier) in the end.

I have attached what i have now (in test) - it seems happy to push the result through to the debug node - but it is pushing the whole object through so i am not sure if this is expected behaviour ? i.e. it is happy to take the temperature from within an object and return the smoothed value in the object ?

Can someone confirm if this is right and expected behaviour ?

[{"id":"70eca549.e2f10c","type":"mqtt in","z":"55f03afc.485ad4","name":"SENSOR","topic":"Fridge_Freezer_Monitor/Freezer/Temperature/SENSOR","qos":"0","datatype":"auto","broker":"fc085dcb.1ad05","x":140,"y":420,"wires":[["d6a7c36d.6f5fa"]]},{"id":"d6a7c36d.6f5fa","type":"json","z":"55f03afc.485ad4","name":"","property":"payload","action":"obj","pretty":false,"x":290,"y":420,"wires":[["38a1ed3e.9d0e22"]]},{"id":"38a1ed3e.9d0e22","type":"split","z":"55f03afc.485ad4","name":"","splt":"\\n","spltType":"str","arraySplt":1,"arraySpltType":"len","stream":false,"addname":"topic","x":430,"y":420,"wires":[["fc22a824.4dc048"]]},{"id":"fc22a824.4dc048","type":"switch","z":"55f03afc.485ad4","name":"","property":"topic","propertyType":"msg","rules":[{"t":"eq","v":"DS18B20-1","vt":"str"},{"t":"eq","v":"DS18B20-2","vt":"str"}],"checkall":"true","repair":false,"outputs":2,"x":570,"y":420,"wires":[["28e9e2f3.b8d7de"],["adbb82d2.c38fe","fd98a4fe.67f848"]]},{"id":"adbb82d2.c38fe","type":"debug","z":"55f03afc.485ad4","name":"Fridge/Freezer Temperature","active":true,"tosidebar":false,"console":false,"tostatus":true,"complete":"payload.Temperature","targetType":"msg","x":780,"y":480,"wires":[]},{"id":"28e9e2f3.b8d7de","type":"debug","z":"55f03afc.485ad4","name":"Freezer Temperature","active":false,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload.Temperature","targetType":"msg","x":760,"y":400,"wires":[]},{"id":"fd98a4fe.67f848","type":"smooth","z":"55f03afc.485ad4","name":"Average Fridge temps","property":"payload.Temperature","action":"mean","count":"20","round":"1","mult":"single","x":760,"y":560,"wires":[["2ac99d17.29e522"]]},{"id":"2ac99d17.29e522","type":"debug","z":"55f03afc.485ad4","name":"Fridge/Freezer Temperature after Average","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","x":1080,"y":560,"wires":[]},{"id":"fc085dcb.1ad05","type":"mqtt-broker","z":"","name":"MQTT-On-Dev","broker":"192.168.1.36","port":"1883","clientid":"","usetls":false,"compatmode":true,"keepalive":"60","cleansession":true,"birthTopic":"","birthQos":"0","birthPayload":"","closeTopic":"","closeQos":"0","closePayload":"","willTopic":"","willQos":"0","willPayload":""}]

Craig

Hi Craig,
One thing you could do is change the output (from the MQTT-In node) to 'a parsed JSON object' as that would mean you could get rid of the 'json' and 'split' nodes in your flow.

ScreenShot089

Hey Dave,

Yep will give that a try and see where we get to.

I was interested though whether is was design in the smooth node and hence will be left there so could disappear further down the track. It could provde quite useful to be able to smooth/average within an object and pass the result through (as it appears to be doing now)

WIll give your idea a go and report back

Craig

Hi Craig,
I'm half-way through writing a tutorial for my IoT students about different ways to read temperature and humidity sensors. I'll post it on the 'Share Your Projects' section when I've finished it.

In the meantime, one of the first things to consider is working out a naming scheme/structure that suits the user's application. For example, my friend Paul, @zenofmud and myself and one of my students have built weather stations that report our local readings from around the world, which are logged to a common database so we can all see the results.

On a smaller scale I have four external infra-red sensors (connected to Wemos D1 Mini devices) around my house that are triggered by 'body-heat'. When a sensor is triggered it will publish a json string (as shown below) to a common topic

On publishReading Do
   Publish,ir/reading,'{"node_number":"node41","level":[ir#level],"location":"house_drive","camera":1,"temp":[ds18b20#temperature]}'
EndOn

The flow running in Node-RED can look at the json string and work out which sensor was involved. Nearly all the units I have running in my SMART home have DS18B20 sensors fiited to them (as they are so inexpensive). The json string also shows the location and a camera number which is used to send a trigger-message to a Raspberry-Pi-Zero-W (fitted with a camera) to take a photo.

I suppose you could say that this application is interrupt-driven, so when body-heat is detected a chain of events are set in motion.

The tutorial I'm writing is going to explain (with the help of Rule Sets in ESP Easy) how a system could be built to send temperature/humidity readings at regular intervals, when instructed to or when something happens.

Oops... sorry this has gone off track from your original question about the 'smooth node'.

Regards, David.

It should do what you want. Easiest way is to just try it :slight_smile:
As you suggest you should just need to point it to the correct property that is a number - so the msg.payload.Temperature is hopefully OK in your case. We do try to convert what is in there to a number - so if it's a string type, but a number (eg "23.5" ) then it should still work.

Dceejay,

Yep i have tried and it is working - my main question was - is this by design or just an anomaly and would it disappear in future, It seems quite nifty it can average the value and then put it back into the object and send it on its way.

Craig

Dave,

Yep i have been using ESPEasy on most of my devices and started moving to Tasmota en masse in the last week. The first stumbling block i came up against was that Tasmota just blurts out all the sensors in a single stream - whereas ESPEasy (as you know) lets you name each MQTT stream. SO if i have 3 x DS18B20 on a Tasmota they are just DS18B20-1, 2 and 3 and all delivered in the same stream

Also they can all only be on a single pin which is giving me some problems with recabling etc

Craig

Out of curiosity - was there something wrong with ESPEasy that caused you to switch? I've personally been using ESPEasy for sensor data and Espurna (alternative to Tasmota) for relays/switches. I've assumed Tasmota was specialised in Sonoff's/relays like Espurna is...

@craigcurtin - it's by design - no intention of it going away.

I had a mixture of different things around the house - some EspEasy, some ESPurna etc as i played with each one.

ESPEasy was good and gave no problems - but the development worries me a little as it seems very limited compared to Tasmota.

I have started to put a lot more time into Home Assistant recently and ESPHome and both of these leverage Tasmota heavily. (can still work with others but better with Tasmota)

There seems to be a good number of projects coming out for monitoring and managing multiple Tasmotas now so it seemed like a good time to standardize.

Craig

1 Like

I guess that makes sense, especially with Home Assistant at least.

Last summer I gave it an honest shot in form of Hass.io image due to my friends appraisal but could not get even the MQTT broker working (related to confusing setup requiring credential access). It baffled me how such a core feature was broken/badly documented for the few months as I continued to follow that I decided I'll just return to using only Node-RED. As a JS/Node.js developer by profession Node-RED is just so much more straightforward for me. :slightly_smiling_face:

2 Likes

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.