Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix fetching of temp_sw in example.py #44

Closed
wants to merge 1 commit into from
Closed

Conversation

stilllman
Copy link

The result I get when calling get_config is layouted like this:
{'sensors': [{'id': 'temp_sw', 'value', '60', ...}, ...], ...}

@foreign-sub Can you confirm you have the same?

@foreign-sub
Copy link

foreign-sub commented Oct 7, 2019

Yes, before switching to API v6, you had:

System Config V5 (DEPRECATED)

SystemConfigV5 has the following attributes:

SystemConfigV5

....

temp_cpum int Read-only

    temp cpum (°C)

temp_sw int Read-only

    temp sw (°C)

temp_cpub int Read-only

    temp cpub (°C)

fan_rpm int Read-only

    fan rpm

Now with API v6:

System Config

SystemConfig has the following attributes:

SystemConfig

....

SystemConfigSensor

id string Read-only

    sensor id

name string Read-only

    sensor display name

value int Read-only

    sensor current value (in celsius degree)

SystemConfigFan

id string Read-only

    fan id

name string Read-only

    fan display name

value int Read-only

    fan current speed (RPM)

@stilllman
Copy link
Author

Hmm, this confirms my intuition that the API version should be hard-coded, either in aiofreepybox or on the client side. Otherwise, scripts written against version v<N> could stop working as soon as the Freebox is updated to v<N+1> :/

@foreign-sub
Copy link

foreign-sub commented Oct 7, 2019

The way i see it, they only support the 'current/latest' version whatever it is. In this particular case i guess they really had no other choice than to rework the schema to support more features with some impact on rrd data also. There is no telling if this may or may not happen again in the future, but i believe this to be an exception.

@foreign-sub
Copy link

foreign-sub commented Oct 7, 2019

The only way i see to prevent any surprises is to default the API to (current) v6

in #22

I made it so you can set api_version to:
default to None -> use default version (6)
server -> use server version with warning (unrestricted)
or any valid 1 < api_version < 8 with warning

aiofreepybox version releases could also follow this scheme to make things easier to understand for users in the long term
(next version would be 6.0.0, then when api v7 is out and tested, first version will be 7.0.0 and so on)

@SNoof85
Copy link
Member

SNoof85 commented Nov 7, 2019

@stilllman what do you think about this ? I have some ongoing changes into home assistant and don't want to work it twice. I'm waiting that you release a new version of aiofreepybox then ;)

@stilllman
Copy link
Author

@SNoof85 I think that the solution proposed by @foreign-sub is the best we can have without rewriting the entire library, as it allows both "use frozen api" and "use latest available api". Since the API version is frozen in home assistant, things should be good.

Why do you want a new release for home assistant? Do you want to integrate some new features? The auto detection is not merged yet unfortunately, is is something else that you would like to use?

@SNoof85
Copy link
Member

SNoof85 commented Nov 12, 2019

@stilllman i have some pending requests about the Freebox integration (mainly on home API) and few more sensors. As i would like also switch to API V6 i'll have some work again to do and this is not really easy to test without a new release (have to clone the repo and i'm not very easy with git commands 👎 )

@foreign-sub
Copy link

foreign-sub commented Nov 13, 2019

Current open PR's cover almost everything still missing in the API with some extras, i'm currently working on typing everything but this is only a bonus and also a long and tedious work, so it's not really required to be finished if you want to do a release soon. I'm pretty much done on every PR on a functional basis, i'd say #22 #39 and #43 adds the most value, then #47 #17, then the remaining ones in no particular order.

@foreign-sub
Copy link

foreign-sub commented Nov 13, 2019

@SNoof85 you can clone my repo with:
git clone https://github.com/foreign-sub/aiofreepybox.git
cd aiofreepybox/
in any dir you like, then switch between branches with:
git checkout branch-name
ex : git checkout add-fbx-detect
but this only allows you to try one feature for each checkout, so what you want to do is:

git checkout add-fbx-detect
git checkout add-meta
git checkout upd-schemas
git checkout add-player-api
git checkout aiofreepybox
git merge add-fbx-detect
git merge add-meta
git merge upd-schemas
git merge add-player-api
git checkout ...
git checkout aiofreepybox
git merge ...

this way you can merge in any branch you like in the aiofreepybox branch then copy the directory in the HA afpbx folder.
Just delete the directory when you're done or restart if you want to reset on an updated version.

@SNoof85
Copy link
Member

SNoof85 commented Nov 14, 2019

This is not a repo problem, home assistant uses pypi packages 😄 that's why i asked to get a release (it was a pypi release).

@SNoof85
Copy link
Member

SNoof85 commented Aug 31, 2020

This one can be merged as soon as we clearly state that API version used must be >=6

@Quentame Quentame closed this Sep 12, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants