🚀 Exciting News: Announcing Daikin Europe Developer Portal! 🚀 #182
Comments
|
Great news @Daikin-Europe ! Hopefully there will be much more information available from the Daikin devices, especially from the Altherma 3 device I would like to see much more details! |
|
Thank you @Daikin-Europe . I have created a new PR #183 that reduces the polling time to every 15 minutes, as you suggested, for everybody to try. |
|
A rate limit of 150 calls is enough for an AC unit, but not for an Altherma, those change much faster, would love to see a higher rate there |
|
As @rospogrigio said, implement local network access! P.S. I will send some feedback to my installer. Until this is fixed I will not recommend this product to anyone. Good hardware, but if you decide to cripple it ... |
|
For the Altherma there is a separate HA integration, at some point I want to extend that integration also with support for the AC devices, see https://github.com/jwillemsen/daikin_residential_altherma |
|
@Daikin-Europe Cool, good news, keep us updated. But basically I agree to the discussed topics above about rate limits vs local access. |
|
1 update per 15 minutes seems a bit low ..? My AC goes from 18 to 23 degrees in 15 minutes (small room).. I can understand limiting to 1 call a minute (instead of 15 seconds) or 150 change operations/day (setting temp/hvac mode), but it's also about showing the actual state in Home Assistant (current/target temperate, hvac mode, on/off), so 15 minutes seems a long time to reflect the current state on your dashboards, which means the dashboard is not really useful. Thanks for the Developer API though, just hope it doesn't cripple the HA integration, instead of making it better.. |
|
To elaborate on my earlier comment. Maybe I am jumping the gun here, but this announcement seems like a crass form of corporate language to me. DAIKIN describing a serious deterioration in thier product as a great new feature for developers. Maybe my concern is unfounded, but there are recent examples of other companies ... this is called enshittification https://doctorow.medium.com/the-enshittification-of-garage-door-openers-reveals-a-vast-and-deadly-rot-eed85da5b0ba As for the corporate speak: you are not making sure you are able to continue this free service. This is not a free service. As customers, we already paid for this feature, so it is not free. I paid for a device, I didn't subscribe to a service. In my case, I paid a 5 digit EUR sum for DAIKIN devices. There is no technical reason for denying local access. This is proven by my Comfora unit with the older WIFI modules (if I had known I would only have installed the cheaper Comfora units and not the more expensive, newer units). Local access works well, no cloud needed (so no cost for DAIKIN to run servers for a "free" cloud service most customers don't want). The only reason to make cloud mandatory is to grab data and lock us into using their apps. The Since my last comment, I found this https://github.com/revk/ESP32-Faikin and ordered several of the pre-assembled PCBs. I fear this will be the only way to truely own the DAIKIN devices that I paid for. But again, please prove me wrong @Daikin-Europe . To all the others who left ❤️ emojis, please re-read the announcement carefully, with the garage door enshittification in mind and your translator for corporate speak turned to "on". There needs to be massive push-back against @Daikin-Europe disowning its customers. |
|
Yes @VolkerH , I see a common trend with several other IOT vendors about this, that set up everything to be cloud-oriented, and then they realize how high is the cost for them to maintain the cloud connection, and consequently start cutting off the service. My Xiaomi vacuum cleaner, for example, now no longer shows the real time map if you make too many requests, and so we users needed so setup a hack within HA in order to reduce the calls and stay within the rate limitation. I really don't understand this approach, as you say local access is faster and more secure. Cloud connection is nice to have as an add-on, but shouldn't be the only way to interact with the device on the network. Just my 2 cents, let's wait and check wheter @Daikin-Europe want to reply something. |
|
I guess @Daikin-Europe will never reply here. Just dropped the "bad news PR". BTW: the same also happened to the VW API for their electric cars. And there even is an annual subscription fee for "connected services". I am/was thinking about purchasing an Altherma. I am now reconsidering. Albeit is is becoming really hard to own any hardware I paid for. General trend. |
The only solution to all of these issues is to go with an alternative (open source) firmware, e.g. Faikin for Daikin ACs and valetudo for vacuum cleaners. Leave their cloud and never look back. Maybe this will make them sane again once enough customers stop using/buying their products. |
|
No Faikin for FTXM71WVMA with wifi controller BRP084C44. Restricting API call frequency to 15m shows that the whole ‘cloud only’ drive was marketing not engineering or customer based at Daikin. Marketing people should only be in meetings at a ratio of 1 in 5. There should never be rooms with only marketing people in them. |
|
The more interesting question from my perspective is how that should work withthe Onecta App? All the non tech users will use the app whenever they want and expect current data ... So the App-API will then maybe not have such rate limits (because honestly else normal users will make big noise) , but an "open API" will have? This also makes not that much sense ... |
I believe the app will be allowed to perform more frequent polling, or possibly it would update -let's say- every 5 minutes and I highly doubt that anyone would notice. Still would be nice from @Daikin-Europe to have some answers to all the questions asked in the thread so far... but they just threw the stone and hid their hand, as we say in Italy 😉 |
|
If polling for dashboard status updates is rate-limited to the imposed maximum of 150 calls/day, that doesn't seem to leave sufficient 'bandwidth' for actual commands? I want to use automations to operate the A/C under my own scheduling and these additional calls would be on top of those performing the 15m polling. And how does this all work out when multiple A/C units are being polled? |
|
If all the units are connected to the same account, with each polling you get the data from all the units so don't worry for this. But you do are right when you say that each command you send is a call that goes on top of the polling commands. |
In which case it would definitely appear that we need a way of setting the polling rate as has been suggested. Personally I think I will be removing the cards from the dashboard as such stale information is offensive. I also wonder if the 'too frequent' polling is what is affecting my use of the Onecta app to control the A/Cs? I don't know if it's a general thing but the response time is lousy when using the app - very often a new setting does nothing and then shortly after the displayed new setting reverts to how the device was. A frequent culprit is "Powerful mode" which needs several goes at selecting it before it engages. |
I noticed that problem as well. I "fixed" it by increasing the polling time to 90 seconds inside the current code. I think the value is definined in init. |
So this lends support to having a user-adjustable polling time. At the moment, this integration would appear to be interfering with my domestic heating system. Can you be a bit more specific about the whereabouts of the polling time you made an edit to? I searched the repo but could only find TIMEOUT = 60 in custom_components/daikin_residential/const.py |
|
The rate limits seem substantially low, and if this is a problem removing local API access seems like you're intentionally removing a great number of use cases. Let me explain my use case (via Home Assistant):
This means I can pre-chill my house while the sun is shining to give us good comfort with no or low energy usage in the evening, while accounting for variable solar input and variable other loads. When the dishwasher is running its heater, the air con temperature is allowed to warm up a bit. |
|
Does these rate limits mean that someone can start the AC from Onecta or IR and Home Assistant will only know after 15 minutes? That is shit @Daikin-Europe . Where is the local control we wanted for months that do not suppose a cost for your cloud? |
|
I have to come back on my previous comment, a rate of 1 times per minute still looks slow when the AC is controlled through onecta and monitored through HA, a rate of 1 times per 10 minutes is really too slow |
|
IMO It's all a bit of an unpleasant mess now. I suspect the choice of rate limiting to 50/day has been set by them to cover half-hourly dynamic energy pricing. It's not been chosen with a view to real time monitoring but for slow 'smart grid' applications. Ultimately this is my goal so I can live without the 'nice to have' dashboard integration. But I'll be sad to have to remove it. And it definitely rules out fine-grained adaptive solar PV integration. My family wouldn't appreciate losing control using the Onecta app on their smartphones - otherwise the brilliant Faikin would be my go-to solution. I currently have polling from HA set to every 5 minutes and it's still getting the 288 calls a day through OK. The Onecta app is still a bit laggy but I don't feel it's any worse than before I started using this integration. |
Depending of the availability of the S21 port, I think you can use both? Eg. the Perfera has built-in Wifi for Onecta, so adding Faikin would allow both Onecta and direct Faikin control I think? |
Possibly, - I know there's a modbus adaptor available for most indoor units and I had the impression both could co-exist. |
|
Is there any updated release ETA on this yet? |
|
Commenting just to note that, while is honourable that Daikin is trying to acommodate some "extreme cases", as others already said that feels way underwhelming. I am sorry this is not acceptable, sadly after expending a good amount of money for the WIFI module, I see myself looking for fakin and the likes. |
|
The firmware was changed to remove local control Immediately after I
purchased the product. 👹
…On Thu, 25 Apr 2024 at 05:23, Hexadecimalism ***@***.***> wrote:
This is absolutely insufferable @Daikin-Europe
<https://github.com/Daikin-Europe>. Your company has basically removed
features I selected your devices for. I can no longer use my automations
whenever the internet is down (which happens more often than I'd like).
—
Reply to this email directly, view it on GitHub
<#182 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAFPYWWCB5KOXUFWOSPIMKTY7ABBPAVCNFSM6AAAAAA7SXPCAKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANZVGY3TINZZHE>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
what morons. |
|
Dear Open-Source Community, We want to announce a new feature to our developer portal: the launch of self-service functionality.
Integrations that were using the temporary client ID Ready to get started? Head over to our Developer Portal to explore this new feature. |
|
Does the self service client id have any implication on the rate limiting? And no word about local api access... |
|
@Daikin-Europe lovely to see you address all concerns expressed in this thread. You can peacefully close the issue now. 🤦♂️ |
|
Tell your friends and everyone you know about this. This is the only way to make them listening. |
Do you have any suggestions for air conditioners that fit that criteria? As far as I know there aren't any |
|
I paid thousands for 5 units and their installation, only to have features I paid for taken away. This is absolutely insufferable. |
Panasonic: Or Midea Group brands (Hualing, Senville, Klimaire, AirCon, Century, Pridiom, Thermocore, Comfee, Alpine Home Air, Artel, Beko, Electrolux, Galactic, Idea, Inventor, Kaisai, Mitsui, Mr. Cool, Neoclima, Olimpia Splendid, Pioneer, QLIMA, Rotenso, Royal Clima, Qzen, Toshiba, Carrier, Goodman, Friedrich, Samsung, Kenmore, Trane, Lennox, LG and much more): |
|
I tried to create an application and setup the daikin_onecta integration using a new client id/secret, but it failed, am I the only one, or more people having the same issue? |
|
Got it to work with daikin_onecta after a restart, will make a new release with an updated readme. |
|
It's funny. I'm in the market for a rather big AC system. But this is a big red flag. The way Daikin is toying around with it's customers is terrible. It's also killing innovation. The airconditioning market is in my opinion very conservative. Daikin just proved that by doing something other players in other markets did 10 years ago and paid the price for. I hope they wake up soon. But it will be too late for my system. |
|
onecta app discovered my daikin unit, but refused to connect. Its said the thailand region is not supported. |
|
I think you should contact Daikin for this question. We can not tell more |
|
Guys I also agree the rate limit of 200 a day is crazy low! I have come up with a work around while is not ideal.. it may allow you to do fine level controls without using up your rate limits, which will allow a more frequent polling interval as you will be splitting up 'controls' and 'data' essentially. Hear me out.. Alexa skill.. doesnt count towards your API calls.. link the onecta account to alexa ensure you can turn your heating on/off as well as your water heater etc now create home assistant booleans in this example I will use these 3 can be exposed to Alexa. Once they are in alexa and the actions to turn them off and on,results in them turning on and off in both alexa and HA now you can create multiple automations, one for when they turn on, and one for when they turn off for example if the 'ALEXA_HOTWATER' is turned on in HA ( by an automation etc) then the action for alexa is to turn on the Onecta (linked) water heater and so on the delay is at most 3-5 seconds Again its not perfect but losing the ability to control your devices due to the rate limit is less ideal! I hope I helped even just 1 person because i'm very happy with the outcome :) |
|
I'm desperately trying to 'get on board' with the new Onecta regime (i.e. learn to live with highly restrictive usage limits) but everything about Daikin's design seems to get in the way. Because I have Agile Octopus energy tariff, I need to be able to turn down (during expensive energy pricing periods), or turn up the A/C (during very cheap or even negative pricing periods). With Agile pricing, there are 48 half-hourly slots and I thought the most efficient way to do this would be to set up the three available schedules (think: cheap, medium, expensive) with appropriate temperature, fan speed, energy saving etc. parameters in the Onecta app. Then my HA automation can switch between schedules in one action at the appropriate pricing thresholds. Except, when switching schedules, no change in state is effected by the A/C until the next timed change in the schedule occurs. I had assumed the unit would say 'oh, a change of schedule - what should I be doing right now in this new schedule?) - but no, the Onecta app spells it out - "Next scheduled action..." showing some future time and state. The only way this might be made to work is to put 48 entries in each schedule - but even then, there's likely going to be a half-hour lag in responding. Anyone facing a similar challenge? |
|
I am pretty sure the command to change a device settings is instant or at least should be. do you mean it does listen to your command but Home assistant wont show changes that fast? I created an automation that refreshes the entity/device here is the code action: homeassistant.update_entity and it will instantly update those entities ( it will use one of your 200 requests) |
No, the command to switch schedules is issued and received instantly. The delay is that the Daikin units, while acknowledging the change in schedule, only obey the new schedule at the next scheduled change in the equipment's settings. I had rather hoped the units would say to themselves 'I've just been switched to a new schedule... what should I be doing right now' rather than 'OK, my schedule just changed... I'll stay exactly the way I am now and defer changes to my settings until the next timed event'. |
|
Aah right. Then as a work around I would add in a change to the AC to
whatever the new schedule would/should do at the same time. So while it's
not picked up the new schedule yet by the time it does. It's already doing
what you wanted ?
Not ideal but there is always a way !
…On Tue, 15 Oct 2024, 09:20 RadianM, ***@***.***> wrote:
do you mean it does listen to your command but Home assistant wont show
changes that fast?
No, the command to switch schedules is issued and received instantly. The
delay is that the Daikin units, while acknowledging the change in schedule,
only obey the new schedule at the next scheduled change in the equipment's
settings.
I had rather hoped the units would say to themselves 'I've just been
switched to a new schedule... what should I be doing right now' rather than
'OK, my schedule just changed... I'll stay exactly the way I am now and
defer changes to my settings until the next timed event'.
—
Reply to this email directly, view it on GitHub
<#182 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEVPI2SSQ35BJ7XMXBBKYZDZ3TF3ZAVCNFSM6AAAAAA7SXPCAKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJTGIYDOOBYGM>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
OK, but the regular scheduling needs to be switched off for cheap/expensive price slots to prevent it overriding the changes. Then I guess the appropriate forced temperature/fan/economy setting for these conditions will have to be made. But then when the pricing lands between the upper and lower limits once again, I hope turning back on the normal schedule will make it change to the appropriate settings for that particular time - but I doubt it will ( I think the only practical way I can cater for the (rather complicated) normal schedule is to go beyond the simple UI automation setup and do something with pyscript. And then I might as well include the two extreme cases in that script. All this would be unnecessary if the schedule switchover was slightly more intelligent. |
|
I created a comprehensive heating automation. You could adapt it to AC I am
sure
Here is is . It's designed to turn on main heating if any radiator calls
for heat. And if all become idle then main heating turns off. Which turns
off my heat pump .
You could let HA do all the scheduling and turn ac on or off based on other
events
alias: Main Heating Control
description: ""
triggers:
- entity_id:
- climate.landing_radiator_thermostat
- climate.bathroom_radiator_thermostat
- climate.phoebe_s_radiator_thermostat
- climate.claires_radiator_thermostat
- climate.wardrobe_radiator_thermostat
- climate.office_radiator_thermostat
- climate.kitchen_radiator_thermostat
- climate.hallway_radiator_thermostat
- climate.claire_s_toilet_radiator_thermostat
- climate.living_room_radiator_thermostat
attribute: hvac_action
trigger: state
actions:
- choose:
- conditions:
- condition: template
value_template: >
{{ is_state_attr('climate.landing_radiator_thermostat',
'hvac_action', 'heating') or
is_state_attr('climate.bathroom_radiator_thermostat',
'hvac_action', 'heating') or
is_state_attr('climate.phoebe_s_radiator_thermostat',
'hvac_action', 'heating') or
is_state_attr('climate.claires_radiator_thermostat',
'hvac_action', 'heating') or
is_state_attr('climate.wardrobe_radiator_thermostat',
'hvac_action', 'heating') or
is_state_attr('climate.office_radiator_thermostat',
'hvac_action', 'heating') or
is_state_attr('climate.kitchen_radiator_thermostat',
'hvac_action', 'heating') or
is_state_attr('climate.hallway_radiator_thermostat',
'hvac_action', 'heating') or
is_state_attr('climate.claire_s_toilet_radiator_thermostat', 'hvac_action',
'heating') or
is_state_attr('climate.living_room_radiator_thermostat',
'hvac_action', 'heating') }}
sequence:
- target:
entity_id: input_boolean.alexa_heating
action: input_boolean.turn_on
data: {}
- conditions:
- condition: template
value_template: >
{{ is_state_attr('climate.landing_radiator_thermostat',
'hvac_action', 'idle') and
is_state_attr('climate.bathroom_radiator_thermostat',
'hvac_action', 'idle') and
is_state_attr('climate.phoebe_s_radiator_thermostat',
'hvac_action', 'idle') and
is_state_attr('climate.claires_radiator_thermostat',
'hvac_action', 'idle') and
is_state_attr('climate.wardrobe_radiator_thermostat',
'hvac_action', 'idle') and
is_state_attr('climate.office_radiator_thermostat',
'hvac_action', 'idle') and
is_state_attr('climate.kitchen_radiator_thermostat',
'hvac_action', 'idle') and
is_state_attr('climate.hallway_radiator_thermostat',
'hvac_action', 'idle') and
is_state_attr('climate.claire_s_toilet_radiator_thermostat', 'hvac_action',
'idle') and
is_state_attr('climate.living_room_radiator_thermostat',
'hvac_action', 'idle') }}
sequence:
- target:
entity_id: input_boolean.alexa_heating
action: input_boolean.turn_off
data: {}
…On Tue, 15 Oct 2024, 18:35 RadianM, ***@***.***> wrote:
OK, but the regular scheduling needs to be switched off for
cheap/expensive price slots to prevent it overriding the changes. Then I
guess the appropriate forced temperature/fan/economy setting for these
conditions will have to be made. But then when the pricing lands between
the upper and lower limits once again, I hope turning back on the normal
schedule will make it change to the appropriate settings for that
particular time - but I doubt it will (I can't test this at the moment) but
if it doesn't, explicitly setting the parameters and duplicating them for
each half hour slot is not even going to guarantee it makes the change on
time.
I think the only practical way I can cater for the (rather complicated)
normal schedule is to go beyond the simple UI automation setup and do
something with pyscript. And then I might as well include the two extreme
cases in that script. All this would be unnecessary if the schedule
switchover was slightly more intelligent.
—
Reply to this email directly, view it on GitHub
<#182 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEVPI2XE2RGG4OU2HZLMMYDZ3VG57AVCNFSM6AAAAAA7SXPCAKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJUGYZDCOBSGY>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Hi, what is the best way to acces Daikin unit by LAN ? |
|
I looked into it and someth9ling called Faikin. But it's very involved. I would suggest ypu get a powerline adapter that gives wifi. And use that wherever your daikin is and connect to that. This will ensure a strong connection. The amount of data it sends is minimal really so the wifi in the same room will sort it |
We dont have wifi for security reasons ... |
Okay, I'll bite. What possible security reasons could there be to not have WiFi? |
|
Yes I am confused too. If you setup wpa3 it will be pretty secure. And even if not secure what is so sensitive that you can't risk it being accessed? Any IOT device can be used to hack your network if someone really wanted to. If you are online you are not safe. The only reason you are not compromised is because people don't know if you have anything of value :) |
Wifi can be accessed from outside and hacked. |
|
Come on guys, please lets stay on topic ... |
|
This thread hasn't been on topic for months. It's just become a general dumping ground of issues and questions. |
and others
Dear Developers and Tech Enthusiasts,
We are thrilled to announce the new Daikin Europe Developer Portal. This platform is dedicated to empowering developers like you to unlock the full potential of Daikin air2air and air2water heat pumps, fostering innovation in the world of climate control.
🌐 What is the Developer Portal?
Our Developer Portal is your gateway to a world of endless possibilities with Daikin products.
Whether you're an experienced developer, a company exploring opportunities or just starting your coding journey, this platform is your ultimate resource for building and integrating with our technologies.
It's a one-stop destination for all things development-related, offering documentation and resources to supercharge your projects.
🛠️ Key Features?
📚 Comprehensive Documentation: Access documentation that provide a deep dive into our APIs, ensuring you have everything you need to get started and excel with your integration.
🚀 Interactive API Explorer: Experiment with our APIs in real time using our interactive API explorer, making the integration process smooth and intuitive.
🔌 Easy integration: Integrate directly onto the Onecta ecosystem with your own units to develop or test your integration. No special hardware required!
🔑 Rate Limitation: To continue offering the Onecta API for free to all our customers a default rate limitation will be implemented.
💼 B2B Business Case Validation: Explore hassle free if your companies business case works together with the Daikin APIs. Get in contact with us when you want to become a partner.
🚧 What's Next?
This is just the beginning! We're committing to expand and enhance our Developer Portal, with new features and resources in the future.
Your feedback and suggestions will be invaluable as we evolve the portal to meet the needs of our customers.
🔧 What changes can already be prepared from your application?
Make your current application compatible with the upcoming rate-limitation of 150 calls/day. This will allow everyone to query at least every 15 minutes for temperature changes in their home of all their devices. Temperature variation in the home is often not so fast that a faster update rate is required.
🌟 Ready to Get Started?
We're targeting beginning 2024 for the first access to the Daikin Europe Developer Portal. With later in Q1-2024 the release of self service within the developer portal.
Get ready to innovate, build, and make a lasting impact with our Developer Portal. We can't wait to see the incredible solutions you'll create!
Stay tuned for more !
Daikin Europe
The text was updated successfully, but these errors were encountered: