Broken by api change - Githubissues

berkinet commented 3 years ago

An API change seems to have broken this module. https://forum.netatmo.com/viewtopic.php?f=5&t=19196

philippelt commented 3 years ago

Many thanks for the information.

After reading the linked post, it seems that there is no way to avoid an API breaking change. Netatmo historic long tradition.

As the previous property "station name" that was used to identify a station is definitely lost and replaced by a home name, I am going to be obliged to remove all station_name features (selecting data for a given station for example) and replace it where it is possible by home name.

They have kindly provided, for compatibility they said, a station_name field but they just decided to provide new content into it ! This is obviously what netatmo call legacy compatiblity 👎

For existing code using the library :

If you don't specify a station name in your code and have only one home, your code should continue to work as expected (the default station will be handled by the default home mechanism)
if you had defined a second home for the use of cameras for example, it may break your code if this home, dedicated to camera use, is selected as the default home and there is no weather station associated.
if you used to specify a station name in your requests, you will have to change your code and replace the station name by a home name

I am working on these changes. If you have any remarks or idea about how to ease transition for existing applications, feel free to provide suggestions...

berkinet commented 3 years ago

Philippe:

Thanks for the quick reply. I use lnetatmo inside of a plugin for a home automation system (Indigo). Since my use implies a separate instance for each home, and I only support the weather module, I created a quick fix by just global changing station_name to home_name in the WeatherStationData class. That works for my needs, though it is not really the right fix.

Richard

On 19 Nov 2020, at 11:58, Philippe Larduinat notifications@github.com wrote:

Many thanks for the information.

After reading the linked post, it seems that there is no way to avoid an API breaking change. Netatmo historic long tradition.

As the previous property "station name" that was used to identify a station is definitely lost and replaced by a home name, I am going to be obliged to remove all station_name features (selecting data for a given station for example) and replace it where it is possible by home name.

They have kindly provided, for compatibility they said, a station_name field but they just decided to provide new content into it ! This is obviously what netatmo call legacy compatiblity 👎

For existing code using the library :

If you don't specify a station name in your code and have only one home, your code should continue to work as expected (the default station will be handled by the default home mechanism) if you had defined a second home for the use of cameras for example, it may break your code if this home, dedicated to camera use, is selected as the default home and there is no weather station associated. if you used to specify a station name in your requests, you will have to change your code a replace the station name by a home name I am working on these changes. If you have any remarks or idea about how to ease transition for existing applications, feel free to provide suggestions...

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/philippelt/netatmo-api-python/issues/43#issuecomment-730294761, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAZLU4J2ANGAR4BW2PCLCFDSQT257ANCNFSM4T2OVVDQ.

philippelt commented 3 years ago

A lot of things look currently broken at netatmo for the moment. The time_utc return for measurement seems lost somewhere in translation. It displays something near 6 hours from reality (thus breaking all attempts to confirm measurement validity).

The IOS app says measurement is a few minutes old but curves are also showing the big shift of several hours...

I used the Web interface to see if things are the same. It's worst, there is the list of sensors on the left column but not any value is displayed as current (probably because they consider values to old to be appropriate). Curves in the middle shows also the big time shift.

I am going to wait some days to see if netatmo can restore normal operations.

For your information, digging in the web menus that I didn't checked for a long time, I discover that despite my station data is not selected to be public (in privacy settings), there were two apps that I didn't know that were given access to my station ! One is a "public pro" weather service ???

berkinet commented 3 years ago

I agree. It makes sense to wait a a few days, or weeks even.

berkinet commented 3 years ago

Thanks. I will download and test in my application today.

berkinet commented 3 years ago

All ok!

Merci, et passez des bonnes fêtes.

On 15 Dec 2020, at 14:31, Philippe Larduinat notifications@github.com wrote:

Closed #43 https://github.com/philippelt/netatmo-api-python/issues/43.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/philippelt/netatmo-api-python/issues/43#event-4114587393, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAZLU4KGTAQBIYAOEDWDRE3SU5QKFANCNFSM4T2OVVDQ.

philippelt commented 3 years ago

Merci, vous aussi !

philippelt / netatmo-api-python

Broken by api change #43