I’m looking for a home controller. So far I’ve found 3, fhem, openhab, and home assistant. Features I’m looking for are, support for eq-3 max cube and eq-3 max thermostat heads, support for I2C, one wire, and ease of writting owm modules and I want to make my own opentherm interface.
Of course it seems like you can’t have everything. fhem has most of the features (max, I2C, one wire) but doesn’t look so nice and documation is rather thin and out dated so it probably fails on ease of writting own modules. Openhab looks nice and has Max but no I2C and writting own modules looks complex. Home assistant looks nice, has good documentation, and looks to be not too complex to write modules. Hence I’m considering giving HA a try, however it looks like this will mean writing my own modules for eq-3 max, as well as I2C, One wire, and my opentherm. Are any of these in the pipeline?
What components would be useful to look at? I was thinking raspberry pi gpio sensor and gpio switch, nest for a set thermostat (any other simpler components with a slider?).
could someone implement this? I’m a python noob but can test [/quote]
Get in touch with the guy who wrote the module. Perhaps he is willing to do the work. There is a statement in the README that the module was written for the integration in Home Assistant. Otherwise the integration of new devices heavily depends on the availability of hardware to test and time.
I’ve written the MAX!Cube support using that library with some additions. Now I’m unsure how to do a pull request, tox doesn’t run on my system due to some locale setting problem.
thermostat:
platform: max
ip:
port: <port, should be 62910>
Thermostats that are already paired are autodetected, should be configured first using the Max! Application for windows.
Configuration is basic, it’s pretty much only actual temperature and target temperature.
An update with a few days of experience with that.
The MAX!Cube is not a very good controller for that, it doesn’t always do what it is told.
So I flashed it to a-culfw and am now doing this via homegear and the homematic component, which also doesn’t completely work, because, as it turns out, MAX! is not the best protocol in the world.
It’s very slow and changes get lost if you do too much in too short a time.
It’s a limitation of the german rules and maybe the implementation. There is a 1% rule which says in an hour wireless traffic must be less than 1% for any one device. Once you hit 1% maxcube stores the messages until the hour is up and if you send too many messages that overflow the available storage in the cube then messages are lost.
It really needs some thought on how the gui handles messages. You can get from the cube how much of the 1% has been used so it is possible to be smart. For example, delay sending a thermostat change temperature for a couple of seconds and dump it if you get another one (i.e. user is twiddling a gui knob, we want to send just the final set command not all the intermediates. Likewise if the user is setting a week’s worth of set points you could store those not for today if the current hour is at say 0.5% until it drops below 0.2%.
On the plus side the low frequency of transmission means it does clash with wifi and it has a lot been penetration through brick walls etc. so you easily get house coverage where wifi struggles.
I do have hopes for the newer EQ3 Bluetooth LE thermostats. From what I have been able to find out, they should be pretty easy to write a component for and hopefully Bluetooth LE is easier to handle.
but can test 