Welcome to Animus Talk

This is where users of Animus Heart can share ideas,
solve problems and inspire fellow enthusiasts.

Animus Heart?

Zwave network problems

I have been using Domoticz as a secondary controller. It has a graphical user interface for setting associations and also shows a graphical neighbor list. I also feel that some of my battery powered devices work better than the mains powered. I guess they are not statically meshed in the same way but instead uses whatever way is possible when they wake up. It is a petty there is no way to manually set the routing table or at least disable meshing for testing purposes.

My graphs are created with a perl script and graphviz. I run it on a raspberry-pi. It connects to the console of the Heart and fetches the “network list” and renders the graph from that and some hard coded information about the nodes (since the command in the console for listing the nodes does not work).

I wish the Z-Wave Toolbox was sold for the European market. I think it is exactly what is missing. In the US Z-Wave uses another frequency and so most functions of the US version will probably not work in the EU. It seems like Z-Wave are used more professionally in the US and that is probably why they have a lot more diagnostics tools there. I think it would be a nightmare to try to have a big scale network of hundreds of nodes with the system we use. There is a Certified Installer Toolkit for the European market but it is quite expensive and only sold to members of the Z-Wave Alliance.

An alternative to the Z Wave Toolbox is the Silicon Labs SDK and Zniffer. Has anyone tried it?


I have to admit that I don’t have any idea of scripting. :confused:

I’ve read about the Z-Wave-Toolbox before, other people had the same concerns that it wouldn’ t work in Europe.

The Z-Way Server has the Zniffer onboard, but I had to find out, that only the traffic from and to the server is monitored and not the traffic between the Heart and the nodes.
Do you think this would work when using the UZB-Dongle and the software from Silabs?

Yes but it will only show the traffic it can hear and that can definitely differ from the traffic the Heart hears. So it will not show a 100% accurate view. I guess best results are achieved by placing the Zniffer as close to the Heart as possible. Since most networks are horizontally spread I would place it on top of the Heart or 35cm (one wavelength) over/below the Heart.


Ah, I remember calculating wavelengths when I was an apprentice. :upside_down_face:

I read that the Z-Stick works in promiscuous mode, as far as I understood ´this means, that it can monitor the traffic of the entire network, or did I get this wrong?

So I wonder what would be the best alignment of the Heart for best range, horizontally or vertically?

1 Like

Yes I also think that promiscuous mode suggests it can listen to all traffic, not only the one addressed for it.

Yes that is a good question, one should probably open up the Heart and check how many antennas there are and what orientation they have. I will probably do just that some time in the future…

1 Like

If you do, post pictures of the carnage? :nerd_face:

Here it is, couldn’t resist :innocent:
All in all it looks very tidy and well-crafted.
The helical thing is the Z-Wave antenna, so I assume that it is best to operate the Heart in a vertical postion.
Hope this is not taken as factory espionage :slightly_smiling_face:



I previously had it in a vertical position but on the side.

Helix in normal mode:

It seems the antenna is optimized for attaching the heart to a wall but I do not find that practical when you might want to move it around to find a god placement radio wise. That antenna should give a doughnut shaped field which you probably would want to have in a horizontal plane. For that the helix should be standing up and if you do not want to attach the device to a wall you will need to place the device upside down on a flat surface as I now have done.


Meanwhile I put mine to the back of a shelf and fixed it with a book, not really an elegant solution but an easy way if you need to move it:

But coming back to the original problem, I did a factory reset a few days ago, really taking my sweet time, the first day I included all mains-powered devices, waited until the next day, did not touch anything, then included my FLiRS, waited again and performed a network-heal.

It worked out fine, looking at the network list afterwards showed routes that looked sensible to me, but a few minutes later, the routes seemed to be completely confused.

For example, an Aeotec MS6 located about 2m in line of sight to the Heart was routed via an Aeotec SS7 in the cellar through a massive reinforced concrete ceiling and then back to the Heart.

Things didn’t get better after including my battery-powered devices on day 3, the routes are changing continously until today, I don’t know if this is the normal behavior of a Z-Wave mesh.

Long story short, the problem with the switches you described are still present, sometimes a switch, or a TRV won’t change it’s state, though indicated in the GUI.

Meanwhile I can tell that this is not a problem with S2-security as I suspected first, since I included all devices with S0 or even no security at all.


Excellent findings! I’m very impressed, and this is things everyone should know. I’ll design a vertical stand today! Mostly because it’s fun :yum: It would also be interesting to know if the routing you describe is normal and usual. It doesn’t sound very efficient.

1 Like

Agreed, this should find it’s way to the FAQs.

Meanwhile the routes seemed to be mostly stable the second day, with little exceptions.
Maybe I was only monitoring the network establishing itself over time.

I think this could possibly be normal behavior, read about Z-Wave Explorer Frame if you want to know the details, think I found a good example for that yesterday:

Here’s a visualization for that:


I found that, when simply passing by the motion sensor, a new route was established, this was also reproducable with other sensors:

I assume, this is what happens when an explorer frame was sent.
After a while, the former route was back.
I performed a network update for node 13, hope this will be permanently saved.

When I go from the bedroom to the livingroom, I am passing up to 5 motion sensors, imagining this happens everytime a sensor sends it’s values, it’s no wonder that the network gets hammered.
But I think this is only supposed to happen for nodes with wrong routes.

Edit just discoverd, that a formerly direct route seemed to be forgotten by the Heart, after triggering the motion sensor the route was recovered:


So, until someone can convince me of the contrary, I have to assume that @daniel.blom and also other folks in the forum were right when suspecting that the Heart has a routing problem. :thinking:

…btw, home office for almost 8 weeks now, so I have plenty of time for that. :unamused:

1 Like

Another example, 2 days later, 3 battery-powered devices suddenly had no working route.
Here’s an example of my 2 Fibaro motion sensors, they worked fine until today:


In this state no alarm cancellation notification will reach the Heart but when passing by the sensors the route was reestablished again.

Found this log entry, seems to be an alarm cancellation report, possibly from a motion sensor, that was dropped for some reason:

1 Like

I observed several times now that there seems to be a correlation between that it is impossible to even turn on a bulb using the App, GUI, voice command or automation and the facts I described above.
After waiting a certain time it works until the motion sensors are triggered again.

Update 2 weeks and a lot of testing and observing later:

Now I take it as evidenced that all this behaviour has to do with fast succession of devices reporting.

I found, that espacially my 2 Fibaro motion sensors, that I always trigger rapidly one after the other when moving through the hallway to the kitchen, caused confusing the routes, also those of other devices.
When passing all 5 sensors, the Heart went completely nuts.

So I slowly started changing the alarm cancellation time of all sensors, until the Heart remained stable most of the time.

Of course, movement isn’t always predictable, especially when running headlessly through my apartment in the morning :smirk:, so sometimes it happens again, but meanwhile very rarely.

I take this as a temporary solution, hope my findings will be considered by the developers.

The main problems that still remain are that battery devices are not reporting their battery status and that, generally the Heart seems to have problems with handling unsolicited reports, like updating wattage from smart sockets.
I’ve seen that reports are dropping in, but didn’t find their way for further processing.


Do we have proof/examples on that the reception actually got better standing vertical or is this a theoretical assumption? (think placebo effect) doesn’t want to be the grinch here but it was just a curious thought if it should go to FAQ :wink:

1 Like

I’m sure with the approbiate equipment you could proof, that it has a positive effect on range and reliability.
After all, it’s simply physics and antenna technology is not esotericism. :slightly_smiling_face:

As soon as my Heart works stable again, I will start up again with Z-Way Server, giving me the abilityto measure the RSSI.

What I can tell, since I also placed my router vertically, I can use my DECT phone on the entire floor, where I needed a reapeater before.
Think a linear dipole antenna is used here, which has the same characteristics like the helical one.


Do @vato have any comments on this topic? :slight_smile:

1 Like

I found out, that the heart seems to require a power cycle every now and then, even when running on the back burner, it was locking up again.
But at least it was stable for almost 2 weeks now after disabling some sensors and automations. :roll_eyes:

Hi all,

The helical antenna should transmit evenly and not have any effect on direction, however this hasn’t been tested on edge devices, please feel free to test this.

Routing can be updated when the Heart receives a frame that has been routed by another node. That’s why you see the routing table being updated sometimes even though you haven’t ran any heal network command.

The upcoming release will have an updated zwave firmware that will work better mostly for battery devices and especially FLiRS. We will require some beta testers for this release and an email will be sent out when Beta is ready. The release has been delayed a bit and we will get back on a release date, the release is planned for this summer.

Take care and be safe :muscle:


But would this explain pointless or no working routes, that I, and other folks here, too, often watched?
I have read and understood, that every device stores the routes to the heart and it’s neighbours that it knows, but I cannot imagine, that all “incorrect” informations only come from the nodes. :thinking:

Really glad to hear that! Will this also effect the Aeotec MS6, that, in my case, are all mains-powered, though treated like battery-devices by the Heart?

HERE!!! I’m your man! :smirk:
Since I cannot use the Heart the way I want, even an early Beta would do.

1 Like

After the Heart went acting up again, I made another observation:

I found that one of my FGMS-001 was still reporting temperature while being completely blind for motion, so maybe command class binary sensor troubles the Heart?
Maybe also CC Basic, not sure which of them they send. :thinking:
Still, the sensor had no working route at his moment.

Edit found out, that the sensor seems to send both.