Closed eknirk closed 1 year ago
If you would like any feedback on the patch then feel free to share and I'll happily review as well as test for my own issues with the integration
I created a PR with a fix. However, as it contains an unsigned commit, the merge is blocked. Maybe @HandyHat can overide it and merge.
@adamlonsdale you may want to just copy my version of sensor.py into your system.
I think I might have solved my issue thanks to you, @eknirk! I've swapped out your change for the below in my test integration and can confirm I'm now getting the exact same figure in my entity state as I am the bright app. I'm interested in you adding just the 2 entries rather than all of them, is there a reason for this?
usage = 0
for reading in readings:
usage += reading[1].value
return usage
I created a PR with a fix. However, as it contains an unsigned commit, the merge is blocked. Maybe @HandyHat can overide it and merge.
@adamlonsdale you may want to just copy my version of sensor.py into your system.
Life saver! Thanks. Immediately energy usage synchronised and same as Bright app. Once again, thanks
I created a PR with a fix. However, as it contains an unsigned commit, the merge is blocked. Maybe @HandyHat can overide it and merge.
@adamlonsdale you may want to just copy my version of sensor.py into your system.
Tested and working great, thanks
Can I ask, would someone be able to advise how to copy the sensor.py into my integration? Thanks
Copy all from here and paste into your sensor.py in custom_components:
Copy all from here and paste into your sensor.py in custom_components:
Thanks @holdestmade for the guidance & @eknirk for the temporary fix, fingers crossed it works.
Hey @eknirk, thank you so much for investigating this! As I'm sure is obvious, I've had very little time to work on this integration recently, so I appreciate you figuring out why it's not working. Don't worry about the unsigned commit - I will review your PR now!
I think I might have solved my issue thanks to you, @eknirk! I've swapped out your change for the below in my test integration and can confirm I'm now getting the exact same figure in my entity state as I am the bright app. I'm interested in you adding just the 2 entries rather than all of them, is there a reason for this?
usage = 0 for reading in readings: usage += reading[1].value return usage
The reason is that there cannot ever be more than two values and a loop would hide the expected semantics.
Copy all from here and paste into your sensor.py in custom_components:
Hi, I have copied all the code into a new file called sensor.py
I restarted HA
I don't see any Gas data, is there something else I need to do?
Did you replace your existing sensor.py ?
Did you replace your existing sensor.py ?
Yes
Do you see Gas data in the Bright app? On 20 Apr 2023 at 14:27 +0100, mcderd-coder @.***>, wrote:
Copy all from here and paste into your sensor.py in custom_components: https://raw.githubusercontent.com/HandyHat/ha-hildebrandglow-dcc/9b9a124b4e38559ff9863847a8a44a368118c866/custom_components/hildebrandglow_dcc/sensor.py Hi, I have copied all the code into a new file called sensor.py I restarted HA I don't see any Gas data, is there something else I need to do? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>
Do you see Gas data in the Bright app?
Yes, I have gas data in the Bright app, this has been working since January when I first used it.
Can you enable debugging for ha-hildebrandglow-dcc, retrieve home assistant.log and send all the entries for custom_components.hildebrandglow_dcc.sensor?
On 20 Apr 2023, at 16:40, mcderd-coder @.***> wrote:
Do you see Gas data in the Bright app?
Yes, I have gas data in the Bright app, this has been working since January when I first used it.
— Reply to this email directly, view it on GitHub https://github.com/HandyHat/ha-hildebrandglow-dcc/issues/330#issuecomment-1516552693, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQOYHDTQA6M4ZOIWMQKXAWDXCFKGTANCNFSM6AAAAAAXBJRMRY. You are receiving this because you were mentioned.
Can you enable debugging for ha-hildebrandglow-dcc, retrieve home assistant.log and send all the entries for custom_components.hildebrandglow_dcc.sensor?
I have just looked and there are now values showing against the sensor and in the Energy integration!
It writes each time values are retrieved. Let it run for 10min after the restart, as the first values are retrieved within minutes.
On 20 Apr 2023, at 17:20, mcderd-coder @.***> wrote:
Can you enable debugging for ha-hildebrandglow-dcc, retrieve home assistant.log and send all the entries for custom_components.hildebrandglow_dcc.sensor?
Yes, I can do that, how long does it need to be left before I get the entries for custom_components.hildebrandglow_dcc.sensor
Does it only write to the log periodically?
— Reply to this email directly, view it on GitHub https://github.com/HandyHat/ha-hildebrandglow-dcc/issues/330#issuecomment-1516611552, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQOYHDQWUUEHNOFY5XBLCCDXCFO4TANCNFSM6AAAAAAXBJRMRY. You are receiving this because you were mentioned.
Since the switch to BST, ha-hildebrandglow-dcc reports wrong consumption data. This is due to a change pyglowmarkt has introduced in the newest version 0.5.5 and which only had an effect when BST came into effect.
pyglowmarkt is now not using the offset parameter of the API any longer and always asks in UTC while handling the local timezone. However, the API now reports back in UTC which has a one hour difference to BST.
ha-hildebrandglow-dcc retrieves the data from midnight until the current time. However, in UTC midnight BST is an hour earlier, 23:00 on the day before. Therefore the API now reports two results, one for the last hour in UTC of the previous day (which is the first hour of the current day) and a second for the rest in UTC of the current day (which is starting at 1am). However, ha-hildebrandglow-dcc expects a single result and therefore only uses the first result, reporting the consumption from midnight to 1am for the rest of the day.
I have a simple patch ready which I currently test and will add soon after some extensive testing.
However, testing so far has also shown a bug in handling the delay in the API which is more complicated to fix.