I have been working on the same problem myself and I just found a solution.
Complete lack of documentation on this feature but I got it working using the REPL API. In the Easi> web interface under configuration, make sure httpd is set to no TLS, no authorization for the following commands to work.
#Set Pin 0 High
curl -X PUT http://192.168.1.136/api/v1/repl -d "io -h 0"
#Set Pin 0 Low
curl -X PUT http://192.168.1.136/api/v1/repl -d "io -l 0"
Then translate that into your Home Assistant configuration.yaml file:
shell_command:
central_heating_on: curl -X PUT http://192.168.1.136/api/v1/repl -d "io -h 0"
central_heating_off: curl -X PUT http://192.168.1.136/api/v1/repl -d "io -l 0"
Depending on your relay type you made need Low for ON, so adjust the commands accordingly. I hope that helps!
I had a similar issue after upgrade 24.1. On 24.1 it only recognized my wireless thermostat, but no longer my actual gas heater. And the logs showed lot’s of those “unknown command” errors. In the end I reverted back to 23.2.6.
Been using amended local csv config files for a while, which added a lot of entities I use now that didn’t seem to be available using the ebusd-configuration repo. Updating to 24.1.1 and reverting to the config files at https://ebus.github.io/ caused the loss of many of those entities. Am back on 23.2.6 contemplating next move.
Update: I found 12 local config files that weren’t updated for 24.1.1. Now updated all entities are back.
Going forward i’ll be sure to highlight ebusd changes in the changelog.
We’ll also propably name the addon versions the same as the ebusd version but use the patch part of the version umber for addon specific changes.
eg:
..
so 24.1.1 will is ebusd 24.1 with an additional update to the HA Addon
i hope that makes sens and eliminates some confusion. however it might cause more confusion as in the ebusd addon reporting version 24.1.1 wich can not be found on ebusd.eu
let me know what you think about versioning and keeping a changelog.
i realize this might be due to the breaking chages of 24.1 but if --scanconfig activated (eg have ebusd scan and identify then load config files from the web) it usually takes quite a while for the scan to be completed and devices identified. your screenshot only shows about 3 seconds.
usually the scan starts after about 10 seconds and takes up to a minute to complete.
Read Only (default: off)
Only read from device, never write to it
note however that you wont be able to scan the bus for device information and thus if you dont already have config files loaded you may have a hard time identifying the correct files needed to decode ebus messages
After using this for almost two year, I had a stable config with local files set up for my system.
Sadly, late last year problems started popping up. Some entities just vanished (mqtt didn’t pick them up anymore) and no amount of restarting could fix it. Then, they would suddenly reappear, sometimes after hours and sometimes after days or weeks.
I tried to figure out why, but never got anywhere.
Eventually I tried updating my config files, bought a new ebusd adapter, but all to no avail.
With the release if 24.1 even more stuff broke and even basic info (like the return temperature, compressor utilisation, fan and pump speed) just vanished. Occasionally they would show up, but rarely.
I checked and found the “breaking changes” thing that I hadn’t expected to affect local config files, but whatever.
Now I switched over to using the Online files, but sadly no joy there either. Right now it’s so bad, that the addon doesn’t even pick up my controller (Sensocomfort 720/3) at all anymore.
I hope there is some way for me or the devs to fix this. I spent a significant amount of time configuring this for my system and right now nothing works the way it is supposed to anymore.
Even if I do get entities to populate, they often report their initial value and then get stuck there forever.
I have a Vaillant aroTHERM+ on VRC 720 and I’ve managed to transition to 24.1. I’m using /jonesPD/ebusd-configuration config file fork locally - this seems to have been quite an actively evolved config library (many thanks to jonesPD et al). Perhaps try that as a fresh rebuild as a suggestion?
Thanks Lukas appreciate your work. To be clear if Read Only is toggled on then “Only read from device, never write to it” yes? My system doesn’t like Read Only toddled to on the addon starts but then stops with error cannot combine readonly with answer/generatesyn/initsend/scanconfig
I’d like to read and learn a lot more about how ebus data / config files and MQTT in particular relating to the HA integration work because my home setup is a bit unusual and I need to tune it a bit more - is there anywhere you might point me?
I think I managed to get my system to work again… sort of.
I pointed the addon to the “next” branch on the github. This brought back my ctlv3 at least, and some other entities.
Now I will have to sift through everything and rebuild my dashboards and automations. Hopefully it will remain stable for a while at least🤞
It’s too early to say how many of the recent issues are now actually gone, but I am carefully optimistic.
After renaming and resorting the most important entities things look OKish. However, it still seems like quite a few entities, like the pump flow get stuck on their initial value and never update…
As initially I struggled to understand the installation process I was experimenting.
Finally got the ebusd working with data flowing. However I had to reinstall HA and after restoring from backup the devices in ebus in MQTT (under SETTINGS->DEVICES) can see any entity data. All of them are at status unknown.
Logs in EBUSD add-on show continuous flow of data and proper binding
I figured to remove all MQTT Ebus devices (bai, 700 etc) but I don’t know how to restore it back as it does not recognise them again.
