I have now activated Drop Raw-data. Incoming data are visible in the openhab.log. Suddenly, 3 “Thing Properties” appear, and they are also in the inbox. Initial tests are working. Wow! Great!
This can’t have anything to do with the activation of Drop Raw-data, can it?
I can always control the device through the Onecta app.
Just out of curiosity: are you actually planning to include this or similar functionality in one of the next releases?
If so, is there an estimate when this would be?
Because currently my Daikin integration is not working due to the API change and I must take some effort anyway - so if a new release can be expected within some weeks, I would wait for it.
Full automation is way more important for heating than for cooling
Before Daikin threw a spanner in the works with the new logging procedure. I had submitted the binding for a pull request so that it could be included as an official binding. And I received a number of comments that I had to incorporate into the binding. These changes affect the settings that everyone must make to continue using the binding. This mainly concerns the naming of “Items”. (This change is not yet included in prerelease 4.1.3-OIDC-1.) Now Daikin has adjusted the login procedure, I have decided to further refactor/redesign the binding. Also in view of the maximum number of requests that may be made. At this point the binding doesn’t care about the number of calls .
I would prefer to just work on this binding, I love building it.
But.
As a full time software engineer I have to do this in my spare time. I also have a wife and children who also want some attention .
Sorry, but I can’t make any promises here when it will be ready.
Couldn’t agree more that this is priority one, as I would expect the installation and update procedure way smoother (currently I am on a RPI4 with OpenHABIan and went through the manual installation by copying the jar files…)
That sounds way familiar, somehow…
Now, to put it more precise - already as a principle I would not rely on any really critical function of a smart home system which depends on a) cloud based services and b) people working on it in their spare time. Which, on the opposite, doesn’t mean it’s not cool if it works!
So, definitely no pressure intended! I’m just interested if you generally consider this idea as a solution for the quirks Daikin put into the API and you at least plan to integrate it at some point in the future.
This “200 calls per day” trash breaks everything in my case. Thank you Daikin
To monitor serval sensors of my Daikin Altherma ECH3O R3 I use ESPAltherma. I poll the data every 30 seconds.
My hardware is a M5Stack Atom lite. I customized ESPAltherma so I be able to make use of the indoor unit’s smart grid functionality and the four (hardcoded -.-) power limits provided by daikin using a M5 Stack 4 Relay Unit and the additional GPIO’s on the Atom lite (the recommended M5StickC has not enought GPIO’s for my usecase).
The combination of Alex’s binding () and ESPAltherma gives me the ability to change values like setpoints and to monitor everything in (relatively) realtime.
Hopefully daikin will change its “we grant a generous 200 calls per day” policy soon…
Actually I got the impression that software is not Daikin’s natural strength.
Hardware is ultimate, but software… not one year ago they broke the cloud access of hundreds of installations with a faulty firmware update and took months to revive.
I honestly do not believe that they will change that 200 per day limit anymore. So we can either hope that one day in the far future everything will.be magically solved by Matter / Thread or we can try to get as much as possible out of these 200 requests.
It may require some work, but at least my personal opinion is that the limit may be annoying, but is not a show stopper.
Anyway, I would never purely rely on a cloud service if it comes to serious monitoring, measurement or even control. So for the real stuff, I use dedicated, independent and local sensors - in the Daikin case it’s temperature and humidity (which the indoor unit does not even measure) for wet bulb temperature and / or dew point. The cloud binding is only used for starting, stopping and setpoints, as well as user interaction detection.
Which brings me to the point what my idea is how it might work:
Either the binding polls on a regular time base, as currently implemented. Simple and sufficient for many use cases.
Or it polls on a trigger - and forget about the counter, monitoring, overlay stuff. Keep it simple. If one decides for triggered polling, it is possible to implement daytime variable rates, events, minimum cycle times and fairy dust. For sure, if you do this, you are able to implement a counter to 200 and monitor the stuff in an OH script yourself … But just keep the binding simple.
The ideal case would be if the API supports push notifications or event hooks. Has someone already taken a look if there may be a chance?
Thanks for all the work and the good discussions so far!
Due to the changes made by Daikin and to make myself independent of the Daikin cloud, I have now installed the BRP069B42 WiFi adapter in an indoor unit as a test.
It worked straight away. For smart home use, I use the Daikin binding and the Onecta app also works with it.
I’ll keep an eye on it for a while and then convert my other indoor unit as well.
I’m really pissed off with Daikin, so today I got the external LAN adapter (BRP069A61) that offers a local API. I will chech HA Integration and try to build an integragion in OH via HTTP binding. Maybe I will document this in another thread. Cheers!
@Alexander_Drent maybe it could be a strategy to integrate local access in the binding. My BRP069A61 has the same local API as your BRP069A62. They are considered “deprecated”, since newer modules like my integrated do not support a local API, but it could be a valuable alternative if Daikin stucks with the 200 request limit. The BRP069A61 and BRP069A62 are still sold products.
I think I understand your frustration, I find it very annoying myself. But on the other hand, this is yet another challenge that needs to be solved. I have been running the last Jar for quite some time now without any problems. Which means, the idea works. For now, I need to incorporate this changes into the pull request branch first. So that it becomes an official OH binding. After this I can add more and more features. I had already a complain from the OH maintainers that the binding was too large for a new binding .
If its an official binding then I have a stable basis to build on. there will be changes between the official release and the current version that everyone is using. Because it was a new project for me, for example, the naming of the Items is not always according to the OH standard. so these need to be adjusted, which also affects everyone who uses the current version. This is also why a stable version is important.
Between you and me, I have an idea of how the number of calls perhaps could be increased.
I’m struggling with the installation, maybe there is a misunderstanding. I removed the old binding and installed new from the ad-on store. i cann add the bridge, add my credentials and than it turns green for some seconds. next step is deactivating, also done. afterwards i should move to home.myopenhab.org/onecta, which obviously does not exist in my enviroment.
do i have to install the actual version of the binding manually?
Hi Linus,
You have to install it manually by coping the Jar to the right place. At the top of this topic are links where to download it. ( PreRelease Tag onecta.4.1.3-OIDC-1)
After you copied it to you system. Start using the Installation Guide you also can find at the top of this page