and that will happen, so there’s something else going on here. It’s either browser cash or your device is not going unavailable. Unavailable in that graph will always show as a gap. You can see it in your own image:
It can’t be browser cache because I see new timestamps at the chart. I record the time when I send the faulty json and that’s the same time the HA chart goes to 0. It takes a minute to update the chart…
I even made the same changes to my energy entities too, the ones I’m using in my energy dashboard.
I changed them like this:
- name: "Airco (Energy)"
object_id: "smappee-kwh-airco"
unique_id: "smappee-kwh-34817A+34817B+34817C"
<<: &common_energy_items
state_class: total_increasing
device_class: energy
state_topic: "servicelocation/1a9cc55c-89d1-4823-896d-99a12ca0b4f2/realtime"
unit_of_measurement: "kWh"
availability_topic: "servicelocation/1a9cc55c-89d1-4823-896d-99a12ca0b4f2/realtime"
payload_available: True
payload_not_available: False
availability_template: "{{ value_json.channelPowers | map(attribute='power') | list | sum != 0 }}"
value_template: "{{ (( (value_json.channelPowers[0].importEnergy|float) + (value_json.channelPowers[1].importEnergy|float) + (value_json.channelPowers[2].importEnergy|float) )/3600000) | round(3) }}"
There I can see very big jumps in energy consumption every time I repost that faulty json. So it’s still seeing this as a meter reset, because it goes to 0 and then back to a high kWh value.
So, yes, we’re missing something here. I’m not sure what. I would expect HA to ignore the value if it becomes unavailable. But somehow it looks like it still records it 
it could also be that you’re looking at old data. Click the show more and set the graph to view the past hour.
I sent the faulty json at 17:02 and at 17:17. Exactly matches the timestamps where the chart goes to 0
You’re missing something ;). I know how this works and your template is what drives it.
So, it’s coming from your json. I just noticed that your energy is using a different attribute importEnergy, are you sure all of them aren’t zero?
will force it unavailable if all the power attributes are zero.
The importEnergy attributes are all > 0, i’m positive 
but the data coming back is showing it’s not when it comes available, and it’s not coming from your template. There’s no ghosts in the machine here. It’s simple. It either comes from your data, or it comes from the template being faulty. Your template is straight forward and it will not produce a faulty zero without an error accompanied in the logs. Therefor, it’s coming from your data.
Change the availability template to use the values you’re summing instead.
"{{ value_json.channelPowers[0].importEnergy + value_json.channelPowers[1].importEnergy + value_json.channelPowers[2].importEnergy != 0 }}"
If we let alone the “energy” entries for now and focus on the “power” entries. You see that the chart still goes to 0W in my screenshots, right? Am I wrong to state that this is incorrect? It shouldn’t be recording 0W because at that time the entity was unavailable?
And again, it won’t. You can actually see it in your image. There’s a gap, but you’re focusing on the data after the gap.
It’s momentarily going to zero before resuming it’s value. So, I urge you to continue to look at your data.
I hear you… There’s a gap and I’m focussing on the data after the gap. But the problem is, why is it going to 0 after the gap and to 152w before the gap… 152w was never posted on mqtt at all. The 0W was only posted because I sent the faulty json manually. It wasn’t repeated by the smappe device or anything.
So it received mqtt data of ± 188W every 15 seconds. then I sent that fauly json manually, in order to test. And then suddenly there’s a record of 152W (where does that come from?). Then there’s a gap because it was unavailable, which is expected. But then it starts at 0 W (which was not posted to mqtt, i checked the logs…) and then jumps back to 188 w (which is the value of the first mqtt post after reposting the faulty json)
I feel stupid because you keep telling me that I need to look at my data … Maybe I am stupid, but I still don’t get it
because, the values in importEnergy are 0 when it resumes. That’s it. There’s no conspiracy here. So you’re getting a update from importenergy when power is not zero. That’s why I said
A great example of this is, what does the sensor do when it populates? Does it populate the list all at once or does it populate the list 1 item at a time?
If it goes one item at a time, your template will have junk data when filling zeros and when populating back up to the correct values.
A couple of messages back I said to let alone the “energy” entities for now and focus on the “power” entities. I said that because the problem is actually the same on both type of entities…
So I was only talking about the “power” entities since, but that wasn’t clear I guess. The importEnergy attribute is not used for the “Stopc: R (bureau) (Power)” entity shown in the screenshots above.
Now, for the record, I changed the availability entity for the energy entities like you suggested (to sum the 3 importEnergy attributes instead) but that didn’t change anything. It’s still seeing massive jumps in energy consumption after sending the faulty json once.
This points to it populating one at a time. This is why I keep hammering “look at your data”.
To me, it seems like you’re looking at your MQTT history incorrectly and assuming that HA has the problem. When I think the error is in the way you’re looking at the data.
For giggles. Make an automation that watches that topic and outputs the value of the data to a persistent notification:
- alias: Topic printer
id: topic_printer
trigger:
- platform: mqtt
topic: "servicelocation/1a9cc55c-89d1-4823-896d-99a12ca0b4f2/realtime"
variable:
value_json: "{{ trigger.payload_json }}"
availability_template: "{{ value_json.channelPowers | map(attribute='power') | list | sum != 0 }}"
value_template: "{{ (( (value_json.channelPowers[0].importEnergy|float) + (value_json.channelPowers[1].importEnergy|float) + (value_json.channelPowers[2].importEnergy|float) )/3600000) | round(3) }}"
action:
- service: persistent_notification.create
data:
message: "availability - {{ availability_template }}, value - {{ value_template }}"
I have just created a new log with “mosquito_sub -h x.x.x.x -u xxx -P xxx -v -t servicelocation/# | grep realtime > logfile”.
I waited for 2 messages from the smappee genius device. Then manually reposted the faulty json file at 18:01:44. Then again waited for 2 more messages on the /realtime topic. This results in a log file with 5 messages where the 3rd one is the one I manually reposted.
You can see those 5 log entries here:
https://pastebin.com/PqJ7AR5c
This resulted in this graph in HA:
The entity configuration was like this:
- name: "Airco (Power)"
unit_of_measurement: "W"
object_id: "smappee-watt-airco"
unique_id: "smappee-watt-34817A+34817B+34817C"
<<: &common_power_items
state_topic: "servicelocation/1a9cc55c-89d1-4823-896d-99a12ca0b4f2/realtime"
availability_topic: "servicelocation/1a9cc55c-89d1-4823-896d-99a12ca0b4f2/realtime"
payload_available: True
payload_not_available: False
availability_template: "{{ value_json.channelPowers | map(attribute='power') | list | sum != 0 }}"
value_template: "{{ ((value_json.channelPowers[0].power|float) + (value_json.channelPowers[1].power|float) + (value_json.channelPowers[2].power|float)) | round(0) }}"
Please try the automation. No offense, but I don’t trust the loggings. The automation will post every seen topic change.
- Invalid config for [automation]: [variable] is an invalid option for [automation]. Check: automation->variable. (See ?, line ?).
- Invalid config for [automation]: [variable] is an invalid option for [automation]. Check: automation->variable. (See /config/configuration.yaml, line 10).
I haven not used automations yet. It should be in automations.yaml, right?
yes, typo, it should be variables
