Homey performance improvement tricks with "many devices"?

Hello,

I have maybe 100 or so devices connected to my Homey (60/40 split between zigbee and zwave) and probably a similar number of flows.
And since I upgraded my Homey to 2.0 I have started to have a lot of issues.
After raising a few support ticket about this with athom they all got closed with various version of “yes, homey is slow and you have to many devices and no the pro model will not improve this as it is due to a design flaw in the zigbee/zwave stacks”.

Too name some of the issues I am experiencing:

  • The app takes several seconds when switching tabs
  • The app does not "preload/cache data so scrolling is a pain as it has to load “the next chunk” all the time.
  • Often motion sensor controlled devices takes 5+ seconds to turn on.
  • Many flows never runs (for instance I have 3 flows triggered by the same event, only 1 or sometimes 2 ever run the rest are just “dead” without any error or notification).

So I am curious if other have similar experiences and what they have tried to resolve the issues…
I have tried a lot of tings my self but it does not seem to get much better…
For instance to resolve the flows not triggering from an event I have have tried to merge the various flows so it there is only one flow per firing event but this is rather complicated and instead creates very complicated flows. I have also tried to reduce the complexity of flows to try to speed up things like motion sensors.
The biggest improvement was removing some apps which were using a lot of CPU (namely the awesome Prometheus log exporter). But I haven’t really noticed any huge improvements. So I am starting to wonder if perhaps athom is right and nothing can be done…

So do the Homey community have som tips and tricks to improve performance with “many” devices?

// Michael Medin

2 Likes

The first two (possibly three) symptoms you describe sound like your Homey is still too busy with something. I don’t see how a design flaw in the Zigbee/Z-Wave stacks could be causing that, but Athom will know better than me.

If your Homey ran okay on firmware v1, it’s likely that changes introduces by firmware v2 could be causing problems. One change I can think of is that flow actions are now started simultaneously; so, if you have a flow that has 10 actions, those 10 actions will start at the same time (as opposed to one-after-the-other on v1), which could overwhelm Homey’s CPU.

Also worth a try is to change the power supply that came with your Homey. The power supply is notorious for causing problems, and replacing it with a similar power supply (USB, 5V, able to supply at least 2A) has solved a lot of issues for other users.

Probably you did, but I had to go through all my flows. First I only did the flows with a warning sign, but later on I discovered that many flows with tags also didn’t work properly. So every flow with a tag I had to control manually. I removed every tag and replaced it with a new tag, mostly the same tag!

I also automatically restart every used app every night and once a week homey itself. This did quite a lot for stability. I also have made flows for restart every app after a crash. These flows didn’t fire untill now(1 month). I have disabled all auto updates including homey. Why should I update when it is working well!

As for the mobile app, it crashes a lot lately. So after 5 changes in 1 flow or a total off 5 changes I save and restart the app. It is as it is. Though quite annoying.

Does the app simply crashes if you make changes in flows or do you also test/run flows? If you don’t test/run flows I don’t see how this could be related to the Zigbee/Z-Wave protocol.

Within developer.athom.com at the performance tab, is there any application consuming a lot? This is a very interesting topic for me as I will be growing towards the amount devices and flows you have and the lack of backup, roadmap and issues with Homey makes me wonder if I should switch to a different platform.

The response you get from Athom support indicates to me again that Homey is more like a toy for small fun domotica purposes and is not intended for this scale.

1 Like

I was talking about the homey app problems. Ofcourse this is no zwave/zigbee issue.

This topic started questioning wise. There are enough “Homey Bashing” topics. For this use the search function

My guess is that the architectural issue is that they “send one event for everything” which means they bog down the zigbee and zwave communications. If you compare hue to Homey this is apparent when changing multiple aspects of a bulb it is instantaneous on Hue where as Homey will first turn it on, then set the color, then set the dim level, then… which takes much longer. But this is again just a guess…

Well, I had to re-build most of my flows during the upgrade so it is difficult to say, but simple flows are pretty much identical and the performance is much worse. But it could possibly be other flows bogging down the system. Cpu load sometimes spikes to over 100%, but generally sits at between 20% and 50% constantly (it never idles).

I will definitely give this a shot and see…

I did that as well but also took the opportunity to rebuild a lot of flows into multiple flows to make them simpler (which might have been an issue).

I’ll give this a shot, when I was having issues restarting homey made things quicker, but did not know you could schedule it.
And if crashing apps could possibly be the cause of my flows not firing?
How do you know if apps crash?

Seems like a reasonable guess. I got the impression myself that communication with Zigbee/Z-Wave is done synchronously: send data to the device, wait for acknowledgement, then send data to the next device, wait for ack, etc. Instead of sending data to all devices as quickly as possible and then wait for acknowledgements.

It could also be a combination of both: send one event for everything and synchronously wait for acknowledgement.

You can see if a app has crashed at the app itself. You also can make a flow which gives a notification when a app crashes.Back in the old days you had to look into every app😏

All flows works perfectly, when testing, if I disable all multiple flows with one enable it also always works.
Only when I have multiple enabled at the same time many of them are ignored.

In the developer view I have never seen anything (but it shows realtime data).
The insight page has some very strange graphs but it is difficult to understand what the graps show, but they definitely look bad (which is also why I am thinking restart might be a good idea).
But this is they way all the apps CPU graph looks o maybe they should look like this?

This is the reason I added a 2 seconds delay for every action at the THEN part. This solved many many problems.

I had the same issue, “fixed/worked around” it by setting a delay to the other flows execution of some seconds (this is where I had one flow calling other flows).

I also don’t know how to read the insights graph, if CPU usage is slowly increasing over time that would explain why a reboot works for some time again. I’ve heared about memory leaks, but then this would be a CPU leak :-). If processes do “hang” or threads keep executing you should see some evidence of that within the app performance monitoring.

The graph shows the “CPU time” metric, which always increases over the runtime of an app and is, therefore, not very useful. You have to specifically watch for sharp increases (like for the IKEA app on July 5th). The drops are most likely because you either restarted the app, or Homey.

IMO, Athom should have opted to graph the CPU usage, which is a percentage of available CPU capability. That way, peaks represent excessive CPU usage, and percentages are much better correlatable.

1 Like

Not sure where you got that information, Homey has always been asynchronous (triggering all actions at the same time), even on Homey v1.
Homey is just a lot faster (or slower with some things?) behind the scenes making it more obvious that it triggers all at the same time.

From what I understood, in v1, actions would be started one-by-one. Homey wouldn’t wait for actions to complete, so the execution was asynchronous, but they were started serially. Whereas in v2, actions are started in parallel.

I could be mistaken, of course, but it would account for the need to add more delays if you have more than one action card, as a lot of people started doing after the v2 release.

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):
image
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.

2 Likes

Java !== JavaScript

I think JS in itself isn’t necessarily fat and slow, but some design choices were made for Homey that are suboptimal on the limited hardware platform that it is (one being each app running inside its own sandboxed process, because Athom doesn’t trust third-party developers, and I get the distinct feeling that message passing between all those processes could have been implemented much faster than it currently is).

I currently run Home Assistant, which is much more bloated (Python 3…), but for me, it performs much better than Homey. One of the reasons being that there isn’t a concept of “apps”: all drivers are running within the same process (not much trust issues there).

This topic is about Homey performance improvement tricks. When the answers is gonna be “quit Homey and move to another controller” then this topic will be closed for that. Plz stick to the topic and try to advice in Homey performance, not in leaving Homey.

2 Likes

This was very interesting, I also have some very chatty fibaro which sends watt reports 0.4 then 0.5 then 0.4 ever seconds or so.
Do you know which setting worked? I have tried the obvious ones but nothing seems to do the trick.

So, you buy devices with a lot of capabilities and measurements and then blame Homey for having to deal with it? Strange…
Better dive into the settings of the device and disable or widen the threshold of some capabilities or buy sensors that are only capable of doing and reporting 1 thing.

1 Like