I am having a incredible frustrating experience, and from what I am reading this is the status quo with ST. I have installed ST for a client, with 69 Z-wave devices, 5 Zigbee contact sensors, 13 Virtual devices.The break down are as follows:
24 X Fibaro Dimmer 2 (Z-wave Plus)
2 X Fibaro Double Switch 2 (Z-wave Plus)
8 X Fibaro Single Switch2 (Z-wave Plus)
2 X FortrezZ MIMOlite (Z-wave)
1x Vision Dual Relay (Z-wave)
3x Monoprice Contact sensors (Z-wave)
2x Ecolink Contact sensors (Z-Wave Plus)
5x Yale smartlock (Z-Wave Plus)
21x Zooz 4in1 Multisensor (Z-Wave Plus)
I have used WebCore and have duplicated the rules in Core, to rule out any issues with WebCore, as it is not official but in beta. (I must also state that I have paused Webcore when running Core)
I have removed everything and started from scratch 5 times, I have replaced the hub with another hub now 3 times. But the issues keeps popping up.
My issues (and questions) are as follows:
- The inclusion process would be a breeze up until around 25-30 Z-Wave devices are added, after this it becomes an hit and miss, some times a inclusion could take up to 2-3 hours before it is included successfully.During the inclusion I would get errors in the app that says it is unable to exchange the secure key. I would then remove it and restart the inclusion process. Other times the hubâs light would stay static for 20-40 minutes and no response, then the process would continue. I have also noticed that the Z-wave radio would at random times turn off and would not come out of this state, even after a reboot. I had to turn off the radio and back on through IDE.
- When all was included and the programming is done it would respond well, through the app and to the rules, then at some random time it would stop all response for around 10-30min, I have noticed that in that time the events is showing âZW Radio offâ and the Z-Wave status would display:
-âSTATE: Not functionalâ
-âHome ID: FFFFFFFFâ
-âNode ID : FFâ
-âSuc ID: FFâ
-âProtocol Version: 3.83â
-âRegion: USâ
But when the system is running well it shows:
-âSTATE: Functionalâ
-âHome ID: THE CORRECT IDâ
-âNode ID : 01â
-âSuc ID: 01â
-âProtocol Version: 5.03â
-âRegion: USâ - When I run a repair I am plagued with âFailed to update protocol infoâ and âFailed to update mesh infoâ. I was told by support that it is perfectly normal to get this errors every time from every device. I also was told that it is a bad idea to run a repair on a network with more than 30 devices. This seems like a nonsense argument. Since some of the devices are as far as 130 meters away from the hub and it would require more than one hob, and how would the routing tables look and get updated if you are not to run a repair? In that case the repair button should be renamed to âBreakâ or âDestroyâ. I have found the repair to run more successful at night with only two errors âFailed to update routeâ. (Which I understand is not a big deal, and the two devices that gave this error is very quick on response).
- During night time when there is no movement and the customer is asleep the events look like this:
But when everyone is up and there is motion it looks like this:
I have to mention that none of the pistons that is running is set to execute during the day as it is set to run only if the LUX levels are below 30 and there is motion. So it looks like it is falling over because of all the motion reports?
Yesterday we were busy adding more devices to the network, and all of a sudden the radio stopped and I could not get it back on again. I then held the reset button in for around 30seconds until the yellow led stayed solid. This reloaded the local OS and brought the radio back on.
At this point the system is responding perfect when there is no motion or no one at home, but the moment the motion starts it will respond well until something random is happening, then it would drop instructions or not get it.
4. Sometimes the app would show a device as "OFF "but indicate the accurate power drawn and the light would actually be âONâ and vice versa. This often happens when the device was turned on via a piston execution.
I have mapped the network out with the Z-Wave toolbox. all the nodes has between 5-20 neighbors, so there can not be a range issue.
Can this be a corruption in the DB, if so how can this be fixed, and why would this happen every time, or is this caused by the ST architecture?
I am pulling my hear out, and the opinion of Smartthings being the best is seriously in question.
When I send a email to support it takes between 1-2 weeks to get a response.
I would appreciate any help.