@BertrumUK thank you - I copy/pasted that code into my sensor_mqtt_gas_import_today.yaml file (alongside Roberts original codes snippets) so I have the following in 1 file:
Still no joy after reloading mqtt entities as suggested by @robertalexa I also rebooted HA as well (as I needed to do another updated) and still no bananas
Can you please search the entities by their unique_id instead of the human name? I still find it very hard to believe they are not there. Not that i don’t trust your word, just that it is suuuuch a weird one that makes no sense whatsoever.
One other thought that i have, I am not sure if you can define multiple of the same property. Like multiple files with multiple declarations of mqtt (haven’t tested, but kinda makes sense it needs to be unique).
So if you are finding yourself in this predicament, try to consolidate all your entities in the same definition place.
PS: I have been doing some work on consolidating all entities under 1 device but it is still a work in progress, especially that i want to check if i can improve on the cost entities to avoid the whole situation with buggy meters that reset to previous value at random in the early hours. Will keep working on it and will update you guys when i have something stable - unfortunately my spare time at the minute is limited, but doing my best . I do however want to give an easier way for people to set this thing up, making it easier for me to maintain it as well. I also am not keen on going the HACS way purely on the basis that users not using HACS won’t be able to benefit. I know it is convenient but… So I will try to provide a just as convenient method but native HA
Addition to my above comment: I have a feeling that the entities have been created with the original setup, then you have tinkered with something but you are reusing old unique ids, so they won’t get created as that id already exists, but you should be able to find the old one. I am running on speculations at this point to be honest.
@robertalexa thanks for the suggestions - it is appreciated as this one has me stumped to. Consolidating into 1 device sounds great but I can appreciate the amount of effort required.
Defining multiple files for the same property works fine - I have other MQTT entities defined without any issues and even my old GlowStick worked with each entity defined in its own file.
I did tinker with electric ID’s so as to not loose historic stats; all the electric entities are working as expected which is the strange thing. Electric entities that I didnt have historic stats for I used your code suggestions and they have created correctly as well.
When I search by unique ID the entities still dont show (including having all filters removed):
Thank you. I will have a look into the code now however if this is the issue I wouldn’t expect electric sensors to be created - all the smart meter files are in separate files but all in one directory for the smart meter. I will certainly double check I don’t have multiple paths though (and I will add a gas sensor into a working electric sensor as seperate entity just to double check)
@robertalexa@BertrumUK now this is strange. I added the “Daily Gas” code that you put up @BertrumUK into the electric import file (entity name was amended a couple of days ago to not loose historic data when stripping out GlowStick code)……….and the entity was created! The file now reads:
I am using Home Assistant and want to see what I am exporting I can see my cumulative total however I want to see today’s export total, is this possible?
If you set your energy dashboard with the export total then the Energy dashboard can break it down for it by time period. Ideally you would get this from the App/API/ecosystem of your solar panels (different integration)
@north3221 thank you for that. Looking over your code, your meter has peak and off peak rates? Is that a SMETS2 meter? My json from the IHD doesn’t have the dual tariff registries unfortunately (I am with Octopus on their Go tariff) but I have SMETS1 meters
It doesn’t come from the meter. the meter just publishes the current rate. The automation adds peak and off peak and updates it each time the rate changes on the meter. I use this then for all my utility meters and calculations of costs
Did you look at the readme for this bit? I commented to say delete these if you dont want them and the sections are commented to say delete in the yaml too.
In fact go is the standard cheap overnight tariff isn’t it, so this will work for you, it will add two additional sensors to the device basically for peak and offpeak (they wont populate till the the rates have cycled). Its the flex one this wouldn’t make sense for, as they would be all over the show (cause I think that one keeps changing rate continually)
Just populate your meter id (in two places) and maybe delete the very last bit that says ‘delete only needed it using utility meters’ and stick it in your automations folder, restart HA and the Glow display device will magically appear
Thanks. I hadn’t noticed the rate changes automatically in the sensor. Lol the rates are wrong for me but that’s down to Octopus not updating rates I guess ( unit prices and standing charges are the old Go rate of 5p off peak and 24p peak rather than 7.5p off peak and 40p peak) - my rates only changed up in August lol
I know this is just the real-time consumption of electricity, but it would be nice to know if others observe the same issue. I should be able to correct it with an if value < 0 use the previous value but just wondered if I’m the only one
@Townsmcp
If you check out entry #15 (June ‘22) near to the top of this (getting very long) thread, you will see that I also experience sporadic massive negative spikes.
The spikes are still visible in the Bright App and, as a consequence, their magnitude obscures the real readings:
You will also see in the next (#16) entry that @robertalexa was extremely helpful in suggesting template modifications to avoid saving readings that were negative. Due to work commitments, I haven’t been able to keep up with all the changes that have been made subsequently so I don’t know if traps to avoid negative readings have been added to the latest template coding? Given most users are not experiencing these spikes I suspect the additional template coding will need to be added.
It would be good to understand why we are both experiencing these large negative spikes. I wonder if our smart meters are similar models.
My meter is via Scottish Power and has various markings including: elster (manufacturer?), AM110R & AS300P.
@JohnWH Generally anything that is deamed to be a general population fix was included in my original post under the Updates section where you can see when and what changed. I knpw this is not ideal, I am still working on a different implementation, just spare time was not on my side, but it will come soon.
Any fixes or debugging specific to users are just in the thread somewhere, although maybe i could include an FAQ in my original post
LE: i have included the template for the negative power issue in the original code as well.
@JohnWH you could be on to something there - I have the same model/make smart meters, fitted by EDF - an Elster AS300P/ AM100R SMETS1 meter. I have requested Octopus replace both gas and electric meter as frequently they don’t get meter readings through (even though the data is on the DCC network and in Bright app) which means I get charged the standard variable rate. In the day time it’s a win for me because I’m on the Go tariff but overnight I get screwed when charging the car