from your description and name, I suppose you are in Portugal, just as me…
I wonder what older models you are talking about, since I also own an older model I’d love to integrate with HA.
Mine is a Equation Ceratec 8 1200W, probably bought around 2014. Any relation with your models? Do only The CeratecPro models have the ability to be controlled remotely?
I was also trying to use a smart plug, but my heater seems to go into stand-by mode when it is disconnected, which ruins this possibility…
Smart plug should work if you leave the heater on and in the manual mode (the button with the hand). Bascially I don’t use any of the schedule features of the heater. when it is on is always in manual mode with the temperature I choose.
Then I do the schedule via HA, node-red, etc… and turn off certain heaters if no one is at home.
PS - I do have one that loses the settings after being 1 day off… I guess is the internal battery that is not in good shape.
How to set this up? I have haverland radiators with app control but no idea how to add to HA. @davefrooney where to copy your script? I am not too much into home assistant.
i have tested haverland-mqtt on linux and able to get some data:
mosquitto_sub -t “HAVERLAND/devs/htr/2/status”
{“sync_status”: “ok”, “mode”: “modified_auto”, “active”: true, “ice_temp”: “5.0”, “eco_temp”: “16.0”, “comf_temp”: “20.0”, “units”: “C”, “stemp”: “22.0”, “mtemp”: “21.3”, “power”: “1800.0”, “locked”: false, “duty”: 100, “pcb_temp”: “34”, “presence”: false, “window_open”: false, “true_radiant_active”: false, “boost”: false, “easy”: false, “runback”: false, “boost_end_min”: 0, “boost_end_day”: 0, “error_code”: 0}
Hi @rancho the script will need to run on a separate device and send the info over mqtt to HA. You then need to add each radiator to the HA config. There are a number of people who started working on a more elegant solution but haven’t had an update in a while. It would be great t make an integration out of this
I made some progress on this, although I’ve run into a pretty vexing problem: the REST node status endpoint appears to return cached/stale data most of the time, even if you change the status via the same endpoint
For example I can change the mode from ‘auto’ to ‘manual’ and see the radiator change state immediately, but the status endpoint will still return the old mode. Previously this issue had been masked because for some reason having the Climastar web UI open causes frequent updates to occur, and I’ve had that open whenever I’ve been looking at this. That UI uses the websocket-based API, so it’s likely that causes the cached state on the server side to be updated as a side-effect. Restarting the physical smart box also causes an update (presumably as part of the handshaking process when it connects to the mothership).
It makes sense that there is some caching and each call to their REST API doesn’t reach out to the physical smart box, but I’m surprised there’s no periodic update. Given that, I expect there is a REST endpoint (or some additional parameter or header) that you can use to fetch an update, so I’ll see if I can find something. Does anyone have any knowledge of this? @nicky@davefrooney did you hit this with your MQTT code (which I would think would suffer the same problem)?
Worst case I guess I can try porting to the websocket API instead (which would be nice to get asynchronous updates). Perhaps @dadoj you have some code to share?
Hello @gr_h_m. Using the REST only is a dead end. It has to be used to “command” the heaters, but the updates are all streamed using the websocket, which uses the https://socket.io/ v3 protocol. At the time I had started looking at it, there was no implementation of this protocol in python.
I had then decided to start using Dart. It should be fairly straightforward to have a dart docker image with required code to keep current state of the SmartBox / heaters using the stream, as well as make the REST requests.
I have done the part to maintain the current state using the stream, but have not had the time to move forward with the rest (and REST:) since. Also, I don’t yet have clear understanding of what it would take to then “connect” it back with HA - that is why I was considering MQTT.
Probably the simplest way to integrate into HA is to expose each heater in the system as a switch, either as an MQTT switch and/or as an HA integration that creates switch entities. Then you can use the Generic Thermostat to act as a thermostat and automatically turn on/off the heater to keep an area within a desired temperature range.
If the Smartbox includes a temperature sensor as well, then you can expose that too as an MQTT sensor and/or create a sensor entity in the HA integration. (I don’t have one yet myself so don’t know its capabilities.)
Alternatively, if the Smartbox supports higher level functions like controlling the target temperature of an internal thermostat, then you will probably want to instead expose the whole system as an MQTT HVAC or create an HA climate integration to do the same.
The SmartBox is a gateway between the “web-app” and the heaters. There is no way to talk to the SmartBox directly.
Each heater has a temperature sensor, three set temperatures (comfort temperature, eco-temperature, freeze-prevention temperature), and many other parameters, some of them read-only, some configurable (power consumption, active state, away temperature offset, etc). They expose the time-based (limited to whole hours only) schedule for the heaters, allowing to switch between comfort / eco temperature automatically when in “auto” mode.
They most closely resemble a HVAC device, as they manage them selves based on mode. But there is more to it depending on the mode.
In addition, there are some information that are mapped to the SmartBox / web-app account - they have their own “home / away” status, etc.
However, all this is available via the socket.io websocket only. So I have all this information available in Dart. That is why I think MQTT is the most viable option to make it available to a HA integration - which would interact with MQTT.
Therefore, there are two components required:
a docker image that listens in on the websocket stream to collect the data and publish to MQTT and listen for MQTT actions and send out those commands to the Smartbox (indirectly via the web-app)
As long as the Docker image subscribes and publishes to MQTT topics that the existing MQTT HVAC integration can parse/use, then you should be able to just configure that integration rather than creating a separate HA “integration”. For example (all untested and hypothetical):
climate:
- platform: mqtt
mode_state_topic: smartbox/mode ## Docker MQTT client publishes current mode state to this topic
mode_command_topic: smartbox/mode/set ## Docker MQTT client subscribes to this topic to receive mode commands from HA
current_temperature_topic: smartbox/status ## Docker MQTT client publishes current system status to this topic (can be a separate topic per attribute or aggregate JSON status topic)
current_temperature_template: "{{ value_json.current_temperature }}" ## extract current_temperature from aggregate JSON topic
temperature_command_topic: smartbox/temperature/set ## Docker MQTT client subscribes to this topic to receive temperature change commands from HA
away_mode_state_topic: smartbox/status
away_mode_state_template: "{{ value_json.away_state }}" ## extract away_state from aggregate JSON status topic
away_mode_command_topic: smartbox/away/set ## Docker MQTT client subscribes to this topic to receive away mode commands
...
(Later on, the necessary HA configuration can be automatically created in HA via MQTT discovery, but I’d suggest getting manual configuration working first.)
It doesn’t sound like it, but you’d need to create a separate integration if the model that is supported by the MQTT HVAC integration is substantially different to the Smartbox model.
I don’t think creating the actual integration is that difficult, I already have one that creates climate entities in HA for all my heaters and it was pretty easy to create. The problem is the stale data because it’s using the REST API rather than socket.io for updates.
@dadoj I’ve been trying to get socket.io communication using python-socketio. It will connect fine and send ping/pongs back and forth, but I can’t get the server to send me a dev_data or update event. It sounds like you got this working in Dart? If you have some code to share it’d be much appreciated.
This socketio stuff is pretty painful to debug. The protocol isn’t well documented and the protocol versioning is annoying (you have to pick the right version of the client library to go with the server, I’m using python-socketio 4.x which should work with the v3 socket.io protocol according to https://github.com/miguelgrinberg/python-socketio).
I managed to get something working with python-socketio last night in the end, it seems the way it handles namespaces and query strings differs from the Javascript socket.io client. I can now receive update events, which is the main thing we need, although not yet the initial dev_data event. I think this is due to namespace handling issue with the python API when emitting events, possibly a bug, so I’ll look into that.
But hopefully now I can get something working in HA, since the update message is all I really need (I think I can get everything else via REST for the moment). Will try that tonight.
