My Homey was heavily overloaded as well, causing all kinds of tiring side effects. I took rather drastic measures; I demoted Homey to a dumb device interface and moved all other stuff to a separate controller.
Here’s what I have at the moment: A Beaglebone Black with a number of self-built services; a (really) smart thermostat; a Telegram bot (I use this to ‘talk’ to my house); a timer service (delays execution of commands); a periodic service (runs tasks at regular intervals); a beacon service (scans BLE devices); a storage and sharing provision for my IP cams; and the heart of it all, the business logic with an http interface, ao.
I’ve written these services in C and C++ with speed as the main design goal. Even wrote my own http/https clients and servers to boost the performance.
I talk to Homey using the REST API. Homey uses the web request logic card to trigger the BB.
Not only did this reduce the number of flows (24 at the moment and shrinking), but also the number of apps and devices. I don’t have any virtual device in Homey, no alarms, no experiments active, no variables and only 7 apps (used to be 17 at some point).
My own controller does a lot more than Homey is ever capable of. Naturally, it is far more easier to build complex behavior in C code than with Homey’s flow editor. Some of the current logic simply can’t be implemented with flows at all.
My goal is to truly automate my house, not to use a phone as remote control. My controller drives lighting, appliances, doors, ventilation and heating, based on presence and selected mode.
The performance is great. The BB is robust and stable and executes all tasks reliable and precise, with two fingers up its nose. The funny thing is that the BB’s load figures are much better than Homey’s (both platforms are identical in terms of memory and processing speed):
Having said that, my Homey used to have loads up to 1 and sometimes even over 1.
Is all ok now? No!
Homey behaves like an ostrich: whenever it gets too much, it just puts its ugly head in the dirt and pretends nothing’s the matter. For example, you can tell Homey to switch off a z-wave device and 99% of the cases it will do so, or give you a notice that something went wrong. But once in a blue moon, you’ll find that one of your devices didn’t switch off, the device appears to be off in the mobile app and no error was reported. In other words, Homey changed the internal device state, even though it didn’t receive an acknowledgement from the physical device. I’m not sure this problem is caused by a large number of devices. My intuition says yes, but it might also be that a large number of devices increases the likeliness of noticing these errors. I have 84 devices connected to Homey, 66 of them are z-wave.
To me, Java in Homey is a design flaw. It is too fat and slow to run on such a light weight platform. Java is still a good choice for simple apps and a great environment for the community, but the core of the system would benefit a lot from faster and leaner compiled code.
I’ll hang around for a bit and see where things are going with Homey and Athom. I still like the friendly pale sphere and I sympathise a lot with Athom’s goal to support all devices in the big wide world, but at the end of the day I want a rock-solid solution. A possible next step is to add a z-wave stick to the BB and replace a few devices for z-wave equivalents, but the prospect of additional work makes me tired already.
I hope Homey improves quickly and I can leave things as they are now.
Some easy things to improve Homey’s performance.
I had a lot of chatty devices congesting the z-wave network. Many devices have sensors that I don’t need, like temperature, or power usage, but still their values are transmitted over the network. So I disabled as many sensors as I could and only kept the ones that I need.
I have some movement sensors that annoyingly send illumination and temperature right after the movement alarm. While Homey is executing the flow to handle the alarm, it also has to deal with the other incoming values at the same time. Unfortunately I can’t silence my sensors, maybe you can optimise yours.
At some point I had two Fibaro switches sending power sensor values twice a second, consuming a lot of Homey’s processing power and z-wave bandwidth. Changing some random settings in the switches, stopped this erratic behavior. Check you z-wave log and see if you have such a problem.
Some appliances (especially the ones with heating elements, like coffee brewer, dishwasher, oven, etc) have a rapidly changing power consumption (PWM). As a result, power sensors might send a lot of updated values, unnecessarily consuming resources and bandwidth. Try to change these settings to receive less updates, or disable the power sensing completely if you don’t use it.
In v2 all events, alarms and sensors are logged. In v1 one could disable logging per item. It annoys me that I can’t turn logging off. I don’t need it, so my Homey is waisting its resources.
