Hi every one.
I have MAX! cube eth gateway which I reflashed with a-culfw. The Device now functions as CUL usb device.
The problem I have is with setting up Homegear add-on (GitHub - yeah/hassio-addons: Homegear as a Hassio add-on). Config files require me to enter serial CUL device and it should be something like /dev/ttyACM0 but there is no such device in /dev.
When I enter “hassio host hardware” I can see the device:
02/15/18 17:33:47.869 Module MAX: CUL “My-MAX-CUL”: Couldn’t read from CUL device, because the file descriptor is not valid: /dev/ttyACM0. Trying to reopen…
02/15/18 17:33:52.881 Module MAX: CUL “My-MAX-CUL”: Couldn’t open CUL device “/dev/ttyACM0”: No such device or address
Slightly OT. Is it working well (besides Hassio addon)?
The original software crashes when is used with the HA component: I think is related to the fact of too much data access (polling or pushing, or whatever).
NOT integrated with HASS the system works, but of course I wish to integrate the system in HASS for using some cool automations.
I used the cube with an original software for few months and had problems losing configuration every week or so (guessing because of the reasons you mentioned) but what drove me away from original software is small sync period with HA but let me start from the beginning…
I bought radiator thermostats and also door/window sensors which reduce the temperature when a door is opened (this works great out-of-the-box) only problem here is that it reacts immediately so when someone goes to the balcony and door are opened and closed inside few seconds. thermostats start to close radiators and then immediately open them which can last for a full minute or two and waste battery on thermostat… It would be great if you could control some sort of delay but you cant do anything about that.
In theory, these door/window sensors could be used for security as well but unfortunately, this is not the case. The original software handles sensors on its level and reduces the temperature on thermostats without HA intervention and then informs HA in periods of ~5min what is current state. So if you open enter through the door (open and close like you would normally do) thermostats would react to this but HA does not know about that which makes them useless security device.
So for your automation, you need to keep in mind of this delay of few minutes which is limiting but some automation is of course possible.
This is the reason I flashed cube with alternative software. That way I lose this MAX! middleware and cube redirects every message to HA… anyway that was the plan at least
That is right. After flashing with alternative firmware only way to make is work is to use via Homegear addon.
The system still has its own functionality (when door are opened thermostat temperature is lowered). I guess that is because cube is not necessary for this functionality because MAX! protocol allows the unit to unit communication but there is no connection to HA because I didn’t manage to setup homegear addon. I can’t set thermostat temperature and stuff like that.
No, I’m trying to solve this on HASS.io first before trying that step. My home is currently quite depended on the working system and reinstallation would be a pain in the ass. I guess I could try to build redundant system on another rpi but this is another story.
Actually, this is the default behavior of the MAX! system. No programming needed.
