I can’t see how that behaviour can be coming from the sensor definitions you pasted. Have a look at what messages are on the MQTT bus using something like MQTT Explorer or if you have a free Pi / Linux machine on the network, install mosquitto and run:
Which looks fine and behaves as expected.
What’s interesting is that i’ve unplugged soil_2, and the values keep incrementing up. it’s now showing 11,896.34202 °F
It also seems that only temperature and possibly humidity are affected.
So the sensors no longer affect each others’ behavior which is awesome!
Bu the rounding isn’t working, so there is still something buggy… but getting there!! i can finally test out several nodes at once!
here is the working code to support multiple sensors:
I don’t think you can use is_state_attr like that… is_state_attr what? You haven’t given it any parameters firstly and it’s only going to return true/false not a number to round anyway…
lol, well i kinda have no idea what i’m doing, just throwing spaghetti at the the wall… what i do know is that it appears to be working as expected as far as i can tell… minus the rounding not working… and it has solved the issue of two sensors affecting each other…
But if there’s abetter what of doing it, i’m all ears!
Thanks in advance!
Your rounding isn’t working and that is why… What are you even trying to do with is_state… is is asking a question (yes/no) not returning something to the template value. So no by your own words it’s not working… you just think it is…
The temperature from soil_1 would add itself to the value of soil_2, and vice versa giving me strange readings.
By trying to solve this issue and fumbling around, this actually appeared to solve that problem and now it all appears to be working except for the rounding.
But like i said i don’t know what i’m doing and just tried something and thought i got lucky…
Another way of explaining is that i have multiple sensors and their messages all come from the same gateway publishing them all the same way, and the means to distinguish what value goes to what sensor was to use the “name” filter as suggested here earlier by another user.
That worked well, but then i noticed the temperature of one sensor somehow was added to the next sensor and vice versa, so the reading were one right one doubled up, one right , one doubled up etc…
I tried changing it to:
is_state_attr("sensor.soil_01_adc")
and the problem stopped, so i figured it worked, except for the rounding…
{{ is_state_attr(“sensor.soil_01_Temperature”) | round(2) }}
{{ state_attr(‘sensor.appdaemon_memory_average’, ‘max_value’) | round(1)}} works for me… rounds to 1
For is_state_attr you must define an attribute and a value. See the above referenced doc.
You still haven’t said what attribute you want… and it looks like you are referencing the sensor you are creating in a value_template that is creating the sensor! - how does sensor.soil_01_Temperature even exist when the same value_template is creating it? This is an impossible loop.
So i basically want to parse the sensor name to send sensor Soil_04 data to home assistant as Soil_4 temp, hum and adc
All the messages come in the same so the name is the distinguishing factor.
What i was doing was suggested by another user to filter using the name, and it seemed to work.
no, because they communicate using lora, and the gateway passes the message on to home assistant as shown in the previous posting.
Another user suggested I uncomment my “topic” in the arduino code, but that gets embedded in the message as well, so a filter again would be used to extract it (i think).
No it isn’t. It’s a filter for the incoming MQTT messages which share the same topic for multiple devices: read from the start. Whilst I agree that using state_attr doesn’t make sense, the structure of the template is fine.
Works thus: if the incoming JSON has a name of Soil_01, take the tempc as the new state; otherwise return the existing state (a “do-nothing” step).
I really don’t understand where the addition problem is coming from, though.