If you are polling often (e.g., all 1000 ms) the chance is very high that you get same data.
My ESP implementation checks for that (if the complete package is the same) and does not update the sensor values. This saves a reasonable amount of data in the DB.
So far I do this kind of checks in none of my integrations that I have created (which actually does not mean anything)
IMHO a value in the HA-DB only get’s updated if the value is actually changing to the previous one… So as data provider you do not have to care, if you provide the same data (or not) - the storage process should (&IMHO will) take care…
But again - this is just my “opinion” here - this opinion is based on the “last update” information that is shown when you open sensor details - e.g. in the case of the Net-Frequency the GUI will update the “last changed” & “last updated” dates, if the value has changed - so it can stick at 50.0 Hz for really a long time - while the other values will constantly be updated…
I haven’t looked into the actual DB in order to verify my assumption - might be cause I am running my HA installation on quite a decent hardware [i5, 6 TB SSD, 128GB RAM] together with plenty of other docker containers…
Ok, then it might be not needed. I don’t know either.
The integration is working for me, with update rate 1 second and is showing just slightly earlier as the Tibber API integration which is running in parallel.
If I rename the old energy counter entity and rename the new one to be same as the old one was, does the energy dashboard get this?
I don’t want to lose the old history in the energy dashboard. I don’t care about the Tibber API data.
this EnergyDashboard is some sort of mystery for me… I would not name entities that have different source with the “same” name…
We have some sort of similar problem with the SENEC Integration… where my recommendation is, to add the NEW entities just as additional source (and just remove the tibber original integration (if you don’t need the prices)…
Another way would be to hard-core hack the DB ids’s as it’s described here:
Hallo Matthias,
vielen Dank fĂĽr die Anleitung um Tibber Lokal einzubinden.
Es hat ales bis zu dem Punkt funktioniert bei dem man unter HACS nach “Tibber Pule Local” suchen soll.
Hier konnte ich keinen Eintrag finden.
Kannst du mir weiter helfen?
Geht in HACS auf Integrationen (z.B. http://192.168.178.203:8123/hacs/integrations), dort oben rechts drei senkrechte Punkte > Benutzerdefinierte Repositories und dort folgendes “Integration”-Repository hinzufügen:
Super, vielen Dank.
Ich bin nun einen Schritt weitergekommen.
Leider bekomme keine Verbindung. (siehe Anhang)
ich habe die IP Adresse(192.1xx.xxx.xx) eingetragen und das Passwort (xxxx-xxxx) Wenn ich im Browser die IP eigeben und unter “admin” das gleiche Passwort eintrage, komme ich auf die Seite von TibberBridge…
Was mache ich Falsch? Kannst dumir auch hier weiterhelfen?
Are there any more instructions on how to get the pulse in AP mode? I have tried everything but it doesn’t want change to a green light.
I cannot find any information about it online, it keeps sending me back to this page ;).
Do you plug/unplug using a micro usb of the ethernet? I have tried both but to no avail. Since the Tibber plugin from HA is becoming more unreliable by the day I would really like to get this working
The bridge needs to be in AP (accesspoint) mode - and I am sorry - but there is only one way to plug/unplug the bridge-adapter - it’s directly plugged into the power supply?! [the bridge is the thing, with the colourful led ring]
Thanks, I totally misunderstood the fact that there is a separate bridge. I only have the pulse. I will have to look for a different approach. Thanks for the fast response!
have fun with that - if you don’t find this Integration useful for you, if you are running MQTT and if the setup is also easier for you - that’s totally fine…
