Showing wrong price data

[abbottcam]

Hi there

I love your code, I'm on Octopus Agile and I was looking for exactly what you programmed. Mine is working, I had to remove '/usr/bin/' from the crontab because there was no such directory. The only thing its showing the wrong price info, my area is the same as yours E-1R-AGILE-18-02-21-A. So Today at 17:20 its displaying 20.5p when it should say 19.47p.

Any suggestions?

Thanks

James

[beararmy]

Hi James, not my project but out of curiosity is 20.5p correct for one hour different? In my own project I neglected to factor in the switch to GMT -> BST In all the places I needed to to start with.

Stef

[abbottcam]

Hi Stef

Thanks for your reply!

It's looking that way, how would i change that? Sorry I'm very new to this!

thanks

James

On Sun, 19 Apr 2020 at 17:53, Stefan Harrington-Palmer < notifications@github.com> wrote:

Hi James, not my project but out of curiosity is 20.5p correct for one hour different? In my own project I neglected to factor in the switch to GMT -> BST In all the places I needed to to start with.

Stef

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/pufferfish-tech/octopus-agile-pi-prices/issues/2#issuecomment-616181412, or unsubscribe https://github.com/notifications/unsubscribe-auth/APIBNNDONAEKWX76QXI6MBTRNMUATANCNFSM4ML3IFKQ .

--

James Abbott 07843448046 LinkLine 02084262200

[beararmy]

Hey again, as I mentioned this is not my project, it's just something I keep my eye on (I do similar in a different launguage). So you'll keep to wait for @pufferfish-tech to take a look. But you've done the right thing in logging an issue on here. I would also say that octopus let you re-download the data for a long time, so you're not going to be permanently losing any data in this time, fear not :)

Stef

[pufferfish-tech]

Hey guys, was wondering if I was the only one who noticed. Undoubtedly it's probably just me using the wrong time code somewhere, I'm looking at it now... :)

[pufferfish-tech]

Yep - initially it looks like the fix to the segments is changing every instance of datetime.datetime.now() into datetime.datetime.now(datetime.timezone.utc)

in octoprice_main_inky.py. (I think its about 5 places)

But: this will still print out the wrong cheapest time because that will be printed out in GMT I assume. I'll give this a test later and try to iron out issue #2 but if you guys fancy trying let me know how it looks!

[beararmy]

The way I went with mine (which is all PHP/MySQL) was to keep everything server side as UTC/0 and only convert to localtime (so here, UTC/+1) when you render it. My logic there was that Octopus explicitly state their API will always return UTC/0 with a modifier.

I assume in python you can do something to get the local TZ where it's running and then just add that modifier on to what you're displaying :)

That's how I tackled this when we switch to BST anyway. ymmv,

^not a python person :)

[abbottcam]

Hey

That seems to have solved the problem, great!

Another question, does the programme round up the price? For example, currently the price (as of 10:17am) is 1.76p but my raspberry is displaying 1.8p.

Thanks

James

Mobile: 07843448046 Website: www.abbottcam.co.uk IMDb:http://www.imdb.com/name/nm2555732/ —————————————————— Sent from my iPhone

On 19 Apr 2020, at 19:28, pufferfish-tech notifications@github.com wrote:

 Yep - initially it looks like the fix to the segments is changing every instance of datetime.datetime.now() into datetime.datetime.now(datetime.timezone.utc)

in octoprice_main_inky.py. (I think its about 5 places)

But: this will still print out the wrong cheapest time because that will be printed out in GMT I assume. I'll give this a test later and try to iron out issue #2 but if you guys fancy trying let me know how it looks!

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[pufferfish-tech]

It does round it to 1 decimal place, yes, so that it fits on the display (normally we don't see single digit prices all the time!)

[abbottcam]

Aha! Thanks!

Is it possible to rotate the display by 180? Just so the raspberry power input is at the top? I’m sorry, I’m quite new the coding!

Thanks

James

Mobile: 07843448046 Website: www.abbottcam.co.uk IMDb:http://www.imdb.com/name/nm2555732/ —————————————————— Sent from my iPad

On 20 Apr 2020, at 10:35, pufferfish-tech notifications@github.com wrote:

 It does round it to 1 decimal place, yes, so that it fits on the display (normally we don't see single digit prices all the time!)

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[pufferfish-tech]

It uses PIL which is a standard library so I imagine you can, I am not sure how to though either.

[abbottcam]

I’ve found out how...

https://forums.pimoroni.com/t/inkyphat-display-rotation-command-changed/9675/2

Put this at the bottom of octoprice_main_inky.py

flipped = img.rotate(180) inky_display.set_image(flipped) inky_display.show()

Mobile: 07843448046 Website: www.abbottcam.co.uk IMDb:http://www.imdb.com/name/nm2555732/ —————————————————— Sent from my iPhone

On 20 Apr 2020, at 11:04, pufferfish-tech notifications@github.com wrote:

 It uses PIL which is a standard library so I imagine you can, I am not sure how to though either.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[Chiny91]

Yep - initially it looks like the fix to the segments is changing every instance of datetime.datetime.now() into datetime.datetime.now(datetime.timezone.utc)

in octoprice_main_inky.py. (I think its about 5 places)

Agreed, that appears to do the trick; works for me also.

But: this will still print out the wrong cheapest time because that will be printed out in GMT I assume. I'll give this a test later and try to iron out issue #2 but if you guys fancy trying let me know how it looks!

Yes, the wrong time, displays one hour early, so GMT rather than BST. Also, at the time of posting, for me (in the SW but presumably not a regional thing), the cheapest price is incorrect. I'm double checking Agile pricing: here.

[Chiny91]

Pending a proper solution from @pufferfish-tech , I've kludged a fix to the "next cheapest time" problem.

# Add just before last occurrence of the_now
import pytz
import time
the_now_local = time.time()
the_now_local = the_now.astimezone(pytz.timezone('Europe/London'))
# Change the_now to the_now_local in next line
time_of_cheapest = the_now_local + datetime.timedelta(minutes=min_offset))

Because (a) this program is UK based, and (b) always on the R Pi platform, I suspect there is no need to worry about UTC and TZ at all, staying local and naive with perhaps something like python-dateutil doing an adequate job, but I'm too lazy to investigate on this sunny day.

[pufferfish-tech]

Both fixed have been included now