I recently tried to integrate my Netatmo devices into openhab2 but unfortunately I discovered a lack of features. The valves are not supported, the device discovery could be improved (e.g. the bridge is not needed to address a device/module) and the OAuth2-Handling does not support the usage of refresh tokens. Since the existing binding is covering the soon deprecated API and there is no java lib which is build against the new one, I build my own lib in Kotlin, including all endpoints defined on the netatmo dev website and complete OAuth2 handling. (https://github.com/navybk/netatmo-java-api)
Furthermore I also changed the netatmo-openhab2-binding code, which currently exists as fork (https://github.com/navybk/openhab2-addons/tree/netatmo_refactoring). So my question after reading the faq about how to contribute: How could I proceed? I need some input for the Valve Thing, should I remove the relay as Thing and is there anyone out there, who could point me to the pitfalls of evolving the openhab2-addons.
I’m not a developer on OH2 but I can say what I’ve seen.
Netatmo comes up on the forum a lot so I’m sure your additions and improvements will be most welcome.
Make sure to give credit where credit is due. And try to work with the current developers of the Netatmo binding. I’d hate to see a repeat of the problems and bad blood generated with the Nest 2.0 binding.
If you are ready to distribute the changes for testing you can release it to the IoT Marketplace and invite netatmo users to download and test it through that avenue. This can give you a good feeling that there are no major bugs or anything you need to deal with to support various user’s weird setups.
When you are ready, you may be ready now, create an Issue and submit a PR. Expect some discussion about the approach. There might be some architectural concerns that may require some changes. For example, there may be work to centralize the OAuth2 stuff into a common library used by all bindings rather than having each binding implement their own. The Kotlin library may have issues as well. I don’t know how well that works with OSGi, Maven, and the rest of the OH build chain.
After a review if there are no show stoppers the changes will get merged into the baseline.
Make sure the README.md file gets updated as well as that is where the page in the docs gets populated from.
One of the pitfalls that is a problem for some developers is any binding that becomes part of the baseline needs to use the Eclipse License and be signed over to the Eclipse Foundation. Some users don’t want to do that so they end up contributing their works over the IoT Marketplace or just offering up a jar file on their github.
Where did you read that the netatmo API we are relying on is soon deprecated ?!
Can ypu point what is the API you are using ?
I think the good approach would be to open a git issue to discuss the change and then when we are ok with your change proposal you could create a PR on the current code.
From my point of view, it is inevitable to implement the new API calls. Especially if the Binding should support Valves. Even the “outdated” lib usage from the automatic swagger code generation in the current release should be a point. As Mentioned before, the TokenRefresh is not handled and even more: the binding has to deal with potential RetroFit-errors, which is clearly a violation in the separation of concerns concept. In fact the Binding should not even know, which concrete implementation the lib is internally using (beside the dependencies). I will start an issue on github for this. Thanks for you comment
Only the thermostat API will be deprecated in the future, not the global API. No impact on support for weather station and camera.
Any contribution is welcome, we just have to take care to not break what is working well.
Why saying that the current binding is “very buggy” while there is no open issue declared in Git ?
You could say “missing features” but what are the known bugs ?
If you know bugs and you don’t expose/declare them, you cannot expect them to be fixed.
This binding is working without any problems in my production environment. I am using the weather station.
I’ve experienced the binding to just stop updating the values without any error or issue. Everything looks good, except that values don’t update. Restarting the binding resolves the issue every time. I haven’t spend enough time doing an analysis or able to provide clear reproducible steps. I understand that I’m not the only one experiencing this issue, so I didn’t think it was necessary to raise an issue. I get your point, but not everybody needs to report every single bug (or apparent bug). I was just offering doing beta testing. Sorry if I offended you.
I can’t confirm Patrick’s observations, I agree with the values in openHAB and on the Netatmo page. In the event log file, information is actually only output if the value changes - works as expected.
In my openHAB system so far I have no problems with the netatmo binding, I would only have expansion requests:
In debug logging also display the read values, not only:
The Netatmo app also shows a rain forecast for the rain sensor.
The whole area of weather forecast would interest me very much. But I’m not sure if this makes sense or should be outsourced to another binding. In general, the same location is used as for the weather station and the forecast data are based on the data of the Netamo stations.
There were issues at a certain time with refresh stopping and bad refresh for camera but this was fixed at least several months ago.
I can’t remember when exactly but I suppose the fix is included in v2.3.
You can certainly find issues and fix in Git.
If you want to test the refactored module: Feel free to test it from https://github.com/navybk/openhab2-addons
Vales are not finished yet, the others modules and devices should work as known. Be aware, that this changes are not for production environment on this early stage.
Yes, that is interesting for me too. I tried to figure out if it is possible, but I could not find a way to access the forecast data of my weather station.
If it will be possible in the future it is ok for me to integrate the forecast service into the Netatmo binding.
Yes, in the kotlin lib the endpoint was added last night. Unfortunatly you need the ClientId and ClientSecret of the NetatmoApp to use this, so it’ not really available without some work I did not recognize until today morning
But it is quite simple to obtain this: Sniffing the OAuth2 call from any netatmo app will provide the data.
It is not possible to access this endpoint with the customer client credentials. The apps themselves are using credentials which are different from these. It may be possible to extract them from traffic sniffing, but I doubt it is a good idea to make them public. To be sure if it is feasable to gain public access for several not documented endpoints I just contacted the dev team.
not really available without some work