Closed mmoerdijk closed 1 year ago
Removing the %z Breaks it at other places. Will reopen when i have a better solution
Is this related to #64 ? The timestamp device class should support the format it is in now.
No I do not think so. This is actually a difference in the time formats supported by the different browsers.
If I use the apex-chars to plot the values of the prices today attribute with the current time format I this on the ipad:
and this in chrome (on linux & windows)
That is apparently due to but mentioned in the link i posted above. Using the %Y/%m/%d %H:%M:%S%z
format resulting in a time looking like this: 2022/11/14 00:00:00+0100
fixes this for the ipad, but breaks it for firefox.
Removing the %z
makes the plot work for chrome, firefox and the ipad, but breaks my other automations that use python.
So I need to find a way that works for all cases (although I do not use firefox so for now I have something that works for me :-) )
this commit works for me too!
this commit works for me too!
Also with Firefox?
Yes even in firefox it works
seems the format should not be fitted to a specific browser/brand. why not use timestamp, and have the frontend solve its own problems? Especially custom cards like apex charts should not be leading for this. My feeling is we should stick to HA guidelines as much as possible, for raw source values.
You are completely right. I did try to fix in the data generator, but apparently my JavaScript skill did lack a bit as i did not know that replace
does only replace the first occurrence and I should have used replaceAll
.
I now fixed it using this as the data generator for the apex chart:
data_generator: |
return (entity.attributes.prices_today.map((record, index) => {
return [new Date(record.time.replaceAll('-', "/")) , record.price];
})).concat(entity.attributes.prices_tomorrow.map((record, index) => {
return [new Date(record.time.replaceAll('-', "/")) , record.price];
}));
@JaccoR Maybe you could add that to the readme?
I might have missed some previous discussion, but I am still using
data_generator: |
return entity.attributes.prices.map((record, index) => {
return [record.time, record.price];
});
and charts are showing just fine. Any reason you are not using 'prices' to have that do the job for you?
See my first post, that doesn't work in safari/ipad app. If it works for you it is most likely because your locale formats the time differently
it would however be a mistake to adjust the code of the integration, to try to catch all devices peculiarities. Safari is known to be a pain, and some frontend things just wont work. Not seeing this on the iPhone? so it might even be tied to the iPad in your case, which would make it even more device dependent.
All I am saying is, the raw source should be as straightforward as possible, and the frontend should take care of it, probably even in core HA Frontend code. If this integration provides the correct format, we should take the issue to HA/Frontend.
iets like you say, the devices locale formatting should handle it. If that doesnt work as expected, file the issue there.
for testing purposes, Ive just ran a few locale settings, and Dutch on the Safari browser (not the HA app) returns this
just like the iOS app on the iPad does. which I suppose is what we are looking for isnt it?
Interesting that it does work in on your ipad. I have an 2019 version that I use as dashboard. Not using safari directly but the HA app.
I agree that the integration should not be adapted, that is why I closed this PR and added an alternative solution using javascript in the ApaxChart config. I only suggested to add that to the readme, because it can help people running into this problem.
When using the prices from the attribute with the apex chart on apple devices, the graph is not rendered due to a bug in safari: https://github.com/apexcharts/apexcharts.js/issues/702
This makes the time formatting use a fixed format that is supported by safari.
Note that while
%Y/%m/%d %H:%M:%S%z
would add the time zone offset in the string like it is now, it breaks in firefox :man_shrugging: