I’m wondering if the price difference you are seeing is network specific. Sorry to use you as a guinea pig, but if you have semi-working code, I’ll get you to potentially raise a PR to help resolve this issue. To try and fix your issue around network, if you are on a recent version or sensor.py can you please try changing line 168 to
params["network"] = self.network_name
i.e. changing networkName to network and see if this works? I encountered something similar when writing tests yesterday but as no one had raised it I thought it was me.
If this does indeed work, we can merge your changes into the code base.
I actually had the wrong thing in my config (had been experimenting). network_name: ‘Jemena’ does work - sorry I missed that.
But going back to the first part of my last post, it turns out the difference between the newest sensor file (says 2 months) and the older one (says 4 months), with regard to that particular line I posted is that there is no self. in front of the current_prices[0].wholesale_kwh_price near the end. Once I added the “self.” into it, it seems to be working?
Is this a deliberate omission, or something that was missed? Without me adding the self. I get sensor error
(Just to recap, I have the 4 newest files, but I added self. to those two lines. With just that change, I seem to have live prices. They aren’t showing exactly what the Amber app is showing, but are very close. Maybe this is due to the app having the half hour price and HA pulling the 5min price?)
Edit: it actually looks like the prices being drawn down in HA appear to be half an hour “ahead” of the forecast prices of the Amber app? Is this as expected?
so I can confirm that using sensor.py from June also works for me.
The price is not quite right though.
Amber app says 24c, hass says 22.77
solar in app is 10c, hass says 8.44
EDIT: Tuttle is right, I think it is showing the next 30 min pricing on mine now.
@knackers84 there’s a few other changes from the 4 month old sensor to the 2 month only sensor. (Like 5min pricing periods etc)
If you are having the same issues I was having, try just having the fresh 4 newest files, then edit sensor.py,
Once in sensor.py, find those two lines I mentioned above, and add self.
to the two of them (one for general, one for solar)
It should read as self.current_prices[0].wholesale_kwh_price if it’s like mine.
So it appears for whatever reason (the changes we made to the sensor file?) the “current price” (Amber General Usage Price) being shown in HA is just the current “forecast” price. (for the half-hour).
So while we now have the sensor and entity working again, it’s not providing the actual live price that the Amber app is putting out?
Based on your feedback Ive taken a look at the sensor.py file. Could you please try this version to see if this now brings you to the correct values compared to the app?
Hi Jon, I’ve found the issue you faced in regard to data being displayed when you are charged to feed into the grid. To correct this, I’ll need to introduce a breaking change into the code.
The currently Amber’s data model, when calculating the cost of energy returns the FiT as a negative value (i.e. you are being charge -$0.08 per KW). In the original release of this code, I rounded this negative value to a positive to be in-line with how Amber displays the value in their app. So, when a positive value (i.e. you are now being charged $0.08 per KW) it was impossible to disambiguate the 2 in the sensor.
So to correct this issue, I need to revert to Amber’s data model where FiT’s will now return a negative value all the time they are revenue generating, and a postive value when they are being charged.
This change is staged in the dev branch on Github and ready to go - however I’d like to know if this may be too disruptive in people automations, as if so I can attempt to write some logic to invert this as per the current implementation, which will mean I won’t be able to correct until I get a bit more spare time. (If anyone else wants to attempt it, you need to remove the abs from ln 98/129 and then wrap a new method around the FiT)
Thanks for making the change Lewis
I’ll give it a crack, my automations are pretty simple, I expect the only changes will be changing
above: to
below: on a couple of automations.
Just for completeness it is possible for both power cost and feed-in to go negative at times, it’s not just feed-in.
Thanks for your continued effort and commitment to this, Amber should throw you a fish for sure!
