hello, would it be possible to add energy usage logging to the Daikin binding? There seem to be two endpoints to retrieve this information /aircon/get_week_power and /aircon/get_year_power. I’m willing to add the code but not sure where the master source code is now (cf updates by @JimT )
The master source code is always on GitHub.com/openhab-addons
I am currently working on a PR to support an additional adapter, but that’s on my own repository until it’s merged.
I’d like to add the energy usage feature, but my adapter doesn’t support it. I wish it did. I wonder how many systems support it, which raises the question of whether it should be added to the binding.
If it weren’t added to the binding, you could poll it separately using http request from your script.
We could probe for it once, maybe in the initialisation function when the binding starts. My adapter returns “ret=PARAM NG,msg=404 Not Found” when I use a non supported endpoint. If it’s not supported we can return “not supported” on the channel. What do you think?
@Paul_Smedley what do you think, considering that perhaps very very few people would make use of this.
My Daikin Airbase supports this endpoints and for sure it is going to be useful for me.
GET http://ip/aircon/get_day_power_ex
ret=OK,curr_day_heat=0/0/0/0/0/0/0/0/3/7/4/6/6/0/0/0/0/0/0/0/0/0/0/0,prev_1day_heat=0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0,curr_day_cool=0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0,prev_1day_cool=0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0
GET http://IP/aircon/get_week_power
ret=OK,today_runtime=316,datas=1900/0/0/100/6700/0/2800
Martin, is yours an airbase? Why don’t the urls contain skyfi/ in front?
I am not sure, it may not be. It is the built-in Wifi controller in the Stylish series.
I have created a pull request with code to support energy reading. For now it assumes that the endpoint is there. I use the aircon/get_week_power_ex endpoint.
I have put the jar here if you want to try it, it will give you six new channels.
http://www.denayer.com/download/daikin.zip
@JimT I’m not opposed to it, but it does add additional complexity to the code. And there’s also the fact that neither you nor I can test it…
Yeah right now I’m working on adding a support for another Daikin adapter that requires authentication, and I have to rely on testers to get back to me each time I tried to fix my bug.
This feature request for energy usage can be so easily done using HTTP action within a user script. Besides, if the binding were to provide the data, it would still need to be processed by a script anyway, so it’s just a matter of replacing the item.state with HTTP action instead, which is why I’m hesitant to add it to the binding.
Example:
If it were implemented in the binding:
val week_power = Aircon_Week_Power.state
Without binding support:
val week_power = sendHttpGetRequest("http://192.168.1.111/aircon/get_week_power")
it wasn’t hard to do and blends nicely with the existing code. If this is in the binding then it displays easily in Paper UI and thus is easier for non-technical users. Pls have a look at my PR.
@wouterd, can you show me your http://IP/common/basic_info and http://IP/aircon/get_model_info please?
I’d like to see if there is any information about energy report ability in either of those, so that:
- The binding won’t poll the energy urls unnecessarily if it’s not supported
- The binding will only poll the enegry info on start up and once a day thereafter
If there is no way to know whether it is supported other than just trying to poll the relevant urls, then upon first encountering a 404 error, the binding will remember this and stop future polling.
I had a quick look at your PR: what is the reason for splitting the weekly data into current week and lastweek instead of just having it all in one channel, since the data came from one source (week_heat includes the data for 14 days?). It seems to me that splitting it this way just makes consuming/processing the data more complicated.
The channel split reproduces what is visible in the Daikin Controller App. It is then easy to visualise the same values in a UI. It’s a little bit tricky because the API starts the week on Sunday and in the app the weeks starts on Monday (as for most people I’m guessing). In the end I’m most interested just in ‘today’ because that can be stored in the DB and visualised with Grafana.
/common/basic_info
ret=OK,type=aircon,reg=eu,dst=1,ver=1_2_51,rev=D3A0C9F,pow=0,err=0,location=0,name=%62%75%72%65%61%75,icon=0,method=polling,port=30050,id=XXXXXX,pw=XXXXXX,lpw_flag=0,adp_kind=3,pv=3.30,cpv=3,cpv_minor=20,led=1,en_setzone=1,mac=XXXXXX,adp_mode=run,en_hol=0,grp_name=,en_grp=0/get_model_info
ret=OK,model=0FC0,type=N,pv=3.30,cpv=3,cpv_minor=20,mid=NA,humd=0,s_humd=0,acled=0,land=0,elec=1,temp=1,temp_rng=0,m_dtct=1,ac_dst=--,disp_dry=0,dmnd=1,en_scdltmr=1,en_frate=1,en_fdir=1,s_fdir=3,en_rtemp_a=0,en_spmode=5,en_ipw_sep=1,en_mompow=0,hmlmt_l=10.0I cannot immediately see / spot an indicator that we can use to determine whether power reporting is supported - can you?
In this case perhaps we’d have to rely on 404 to not perform the polling for units that don’t support it.
Perhaps all of the Euro Daikins support it?
edit: looking at https://bitbucket.org/mustang51/pydaikin/src/master/pydaikin/daikin_base.py seems pydaikin checks the URL to see if it’s supported…
It seems that they just poll the url regardless.
I’ve had a look through their code. I like their approach of merging all the data in one whole big pot. It simplifies things a bit.
Thanks Wouter, works great! Would be very nice if this is part of the official binding.
It seems that someone else had submitted a PR to do energy reporting in a different manner and his code has been merged.
it seems a bit pointless that I had already created that code and that someone else has had to do the same work. On top this doesn’t really inspire me to do more work on openhab. @cpmeister