DanalockBTZE100Square status report issue

Discussions about Z-Way software and Z-Wave technology in general
User avatar
marco
Posts: 85
Joined: 03 Dec 2015 19:50

DanalockBTZE100Square status report issue

Post by marco »

Hi dears
in a recently updated z-way v4.1.0 revision (razberry 500 on raspberry 4), there is a minor issue with DanalockBTZE100Square devices.
In a totally random way widget of the device reports the correct or wrong status.
What happens is that if the smart lock is locked and I push the open button, even if the smart lock receives and executes the right command, often the widget icon turns correctly to open and then suddenly comes back to close.
Vice versa when I push the close button.
This behavior can be overcome from a pc or when the two buttons for opening and closing are present in the widget icon. In this case, knowing whether the lock is physically open or closed, it is possible to continue pressing the button relating to the desired action until the desired result 8status change) is obtained (but this almost always corresponds to an overforce of the lock which tries to rotate when it has already reached the end of its stroke...).
When using a smartphone the problem is binding instead. In fact, in most apps, the lock widget consists of a single button corresponding to the widget icon. It is assumed that the icon changes status (showing different icons with different colors) and shows whether the lock is open or closed, but if the change of state does not take place correctly, it remains blocked in the condition of being able to only open or only close. This means that with the smartphone you often remain in the condition of not being able to open if the door is closed or vice versa.
At the moment, the only way to fix the problem on smartphones seems to be to use two separate buttons.
One to open and the other to close. Doing so loses status information....not properly a good thing...

As far as you know, is there a way to make sure that the state of the requested action, received and performed by the lock, is the one reported by the widget?
Marco
seattleneil
Posts: 172
Joined: 02 Mar 2020 22:41

Re: DanalockBTZE100Square status report issue

Post by seattleneil »

To efficiently troubleshoot this issue, more information is needed.

1. When you use Z-Way to operate the lock, does the lock operate correctly?
2. Does the widget display the correct status some of the time, never, or all of the time when you operate the lock using Z-Way?
3. When you manually operate the lock, does the widget update to the correct status some of the time, never, or all of the time?
4. Check the timing stats of the lock by accessing the expert UI at http://[IP address of your raspberry 4]:8083/expert/#/network/timing. What does it show?
5. Check the signal strength for packets sent to/from the lock by accessing the expert UI at http://[IP address of your raspberry 4]:8083/expert/#/installer/history. What does it show?
6. Check packets statistics by accessing the expert UI at http://[IP address of your raspberry 4]:8083/expert/#/installer/packets. What does it show?
7. Check RF noise by accessing the expert UI at http://[IP address of your raspberry 4]:8083/expert/#/installer/rssi. What does it show?

Note that the Z-Way expert UI has other diagnostic tools and a log file. You may want to check them out as they can be very useful for solving issues. From your description, 1 possible explanation is that packets sent by the lock are not being received reliably by Z-Way (either a signal strength, routing or noise issue).
User avatar
marco
Posts: 85
Joined: 03 Dec 2015 19:50

Re: DanalockBTZE100Square status report issue

Post by marco »

Thanks for your reply seattleneil.
I've already checked some of what you suggest. Anyway, I'll recheck everything asap and come back.
Marco
User avatar
marco
Posts: 85
Joined: 03 Dec 2015 19:50

Re: DanalockBTZE100Square status report issue

Post by marco »

Hi settleneil, I'm here with my updates.
seattleneil wrote:
14 May 2023 08:10
1. When you use Z-Way to operate the lock, does the lock operate correctly?
No. If I use Z-way to lock and unlock the device it seems to operate but, as per my previous writing, not always widget change its status as requested and this means that we remain blocked in open or close mode.
seattleneil wrote:
14 May 2023 08:10
2. Does the widget display the correct status some of the time, never, or all of the time when you operate the lock using Z-Way?
The widget displays the correct status only sometimes but with no predictable reason. I add that locks are not able any more to operate manually using the side touch button: they operate rotating always in the same direction while it is supposed that they should go in a direction at the first touch and in the opposite direction at the second touch.
seattleneil wrote:
14 May 2023 08:10
3. When you manually operate the lock, does the widget update to the correct status some of the time, never, or all of the time?
Never. It isn’t able any more to change direction of rotation.
seattleneil wrote:
14 May 2023 08:10
4. Check the timing stats of the lock by accessing the expert UI at http://[IP address of your raspberry 4]:8083/expert/#/network/timing. What does it show?
1.png
1.png (28.79 KiB) Viewed 7714 times
Device 8 and 9 are no powered.
seattleneil wrote:
14 May 2023 08:10
5. Check the signal strength for packets sent to/from the lock by accessing the expert UI at http://[IP address of your raspberry 4]:8083/expert/#/installer/history. What does it show?
Most recent page shows this
2.png
2.png (53.04 KiB) Viewed 7714 times
seattleneil wrote:
14 May 2023 08:10
6. Check packets statistics by accessing the expert UI at http://[IP address of your raspberry 4]:8083/expert/#/installer/packets. What does it show?
3.png
3.png (35.49 KiB) Viewed 7714 times
seattleneil wrote:
14 May 2023 08:10
7. Check RF noise by accessing the expert UI at http://[IP address of your raspberry 4]:8083/expert/#/installer/rssi. What does it show?
4.png
4.png (71.54 KiB) Viewed 7714 times
seattleneil wrote:
14 May 2023 08:10
Note that the Z-Way expert UI has other diagnostic tools and a log file. You may want to check them out as they can be very useful for solving issues. From your description, 1 possible explanation is that packets sent by the lock are not being received reliably by Z-Way (either a signal strength, routing or noise issue).
Most of the electrified devices in that network are used not only to operate circuits but also to realize a good mesh able to route signals.
5.JPG
5.JPG (62.97 KiB) Viewed 7712 times
So, considering that I start to have similar issues with other products by fibaro (I’ll check them out and eventually I’ll open a new topic if needed), I guess could be something new that cause this strange behavior. What you can tell me?
Marco
User avatar
marco
Posts: 85
Joined: 03 Dec 2015 19:50

Re: DanalockBTZE100Square status report issue

Post by marco »

Hi dears, here I am with other clues. What I said about Fibaro device I think (but I can be wrong…) is related to this behavior.
This case is about a Raz500 on a raspberry pi 3B+ with Zway V4.1.0 and Fibaro FGBS-001.
Fibaro device generates 4 widgets: 2xSensor General Purpose and 2xGeneral Purpose alarm.
Depending on the configuration settings, it is supposed that the sensors widget should change status depending on the actual status of a circuit connected to the relevant contacts. This doesn’t happen every time. The widget stands still in the same status depending on the status read when an update is requested. The way to overcome this is to require a periodical update of the widget. Actually, I don’t know if there is an app that can let you update every single widget every second but to temporarily solve the problem I used an API command to update, calling it in a while true bash cycle and checking it by cron for consistency.
Marco
seattleneil
Posts: 172
Joined: 02 Mar 2020 22:41

Re: DanalockBTZE100Square status report issue

Post by seattleneil »

On the good news side, the information you provided shows you don't have an RF noise issue (channel 1 is used for 9.6 and 40 kbps communication and channel 2 is used for 100 kbps communication). Also, packet statistics show devices 16, 22, 23, 25, 26 and 35 are operating well.

On the bad news side, packet statistics show device 27 routing needs to be fixed (delivery success needs to be 100% and rerouting should be as low as possible). You should be able to fix this by either performing a network reorganization (expert UI->Network->Reorganization) or manually adding a route. In addition, the timing info for device 3 is strange. Although the signal strength for device 3 is excellent, for some unexplained reason, 2 of the 10 packets had unusually large delay values (410 and 670 milliseconds) and 8 packets had excellent timing stats. Note that long delays for battery-powered devices is normal since these devices are designed to only wake up at periodic intervals.

Packet statistics were missing for devices 3, 14, 32 and 33. As a result, not much can be said about these devices. If these devices are switches, you can force packets to be sent and received using the expert UI->Control->Switch->Update All button. If these devices are sensors, meters, thermostats or locks, select the corresponding category in the Control menu and press the Update or Update All button. After you've generated packets, Z-Way should update the packet statistics and timing information for these devices.

You did not say which devices are Fibaro FGBS-001 devices or the Danalock. From a search, it looks like the Fibaro FGBS-001 may be a legacy Z-Wave device (i.e., not Z-Wave Plus or newer). Although I cannot tell from the information you provided, I can share a terrible experience with a Leviton legacy Z-Wave switch that would claim strong signal strength to adjacent nodes, even though the Leviton switch did not have direct communication to the other devices. As a result, a single Leviton switch would cause Z-Wave packets to be mis-routed for other devices. Z-Way's tools can show you routing issues, but only if there is packet traffic to/from these devices. A nice way to visualize the Z-Wave routing is to use Z-Way's route map (expert UI->Analytics->Route map). Unfortunately, the default routing map diagram (the hub-spoke wheel) is difficult to decipher. To make sense of the routing map, it's very helpful to upload a background image of your floorplan and move the nodes to where they are located on your floorplan. Here's an example:
Floorplan.jpg
Floorplan.jpg (353.59 KiB) Viewed 7678 times
Once you've uploaded the image and moved the nodes to their location on your floorplan, the information shown on the route map should be much more intuitive. The screenshot shows what appears when I hover my mouse over node 13. I can see Z-Way routes packets to this node via node 12, and node 13 routes packets to Z-Way via node 12 or directly, with 100% delivery rate and 0% re-routing.
User avatar
marco
Posts: 85
Joined: 03 Dec 2015 19:50

Re: DanalockBTZE100Square status report issue

Post by marco »

Hi, I'm sorry, you are right. Danalock are battery devices only (2,4,5 ...8 and 9 not powered). FGBS-001 are on another plant.
Moreover, I can add that FGBS-001 work properly (no issues) on a third plant based on raspberry pi 3B+, raz500 and zway v3.0.4-33-gfb22f31 (too many devices on this network to perform an easy update...I need to plan s specific job to do this).
I'll come back with more detail in the next days.
Thanks for now.
Marco
User avatar
marco
Posts: 85
Joined: 03 Dec 2015 19:50

Re: DanalockBTZE100Square status report issue

Post by marco »

Hi dear, here I am with a more detailed route map where we can see danalock smartlock (in green).
Cattura.JPG
Cattura.JPG (162.23 KiB) Viewed 7611 times
Of course, it says nothing more than before to me but I'm sure could be of help to you.
I don't think there are routing problems. Devices are far from the controller no more than 6 or 7 meters, there are no significant obstacles between and moreover, there are between repeaters devices.

I recently had a problem also with Z-WavePlus Fibaro FGMS-001. On a fresh new system (raspberry 4, last updated Bullseye, zwave V4.1.0) I installed 5 new Fibaro multisensor. Trying to fine-tune the configuration of the sensors, they suddenly stop working. No more status updates when the motion sensor is triggered. So, by attempts, I interviewed all of them and looked for a minimum number of parameters to be modified without losing the required functionality (to sense for no desired presence in the rooms). Actually, I didn't have the chance to verify if temperature, luminosity, and other reporting work properly...

I confirm that FGBS-001 is not Z-WavePlus but I don't think this is related to the inappropriate behaviors because, as said before, on a v3.0.4-33-gfb22f31 Zway version I don't have status update problems.
Marco
seattleneil
Posts: 172
Joined: 02 Mar 2020 22:41

Re: DanalockBTZE100Square status report issue

Post by seattleneil »

From the route map you sent, it looks like there's a metal wall (shown below in the red rectangle) that's blocking direct Z-Wave communication between the controller and devices 25, 26, 27 and 32. Since there's been no traffic for door locks 2, 4 and 5, I can't tell how packets to/from the door locks were routed.
floorplan-annotated.jpg
floorplan-annotated.jpg (98.94 KiB) Viewed 7607 times
Although it may seem counter-intuitive to not have the controller in a central location, moving the controller to the location marked by the red X should improve Z-Wave communication reliability since more packets would be directly routed. If you do move the controller, you must perform a network reorganization to update the controller's routing table. You will also need to manually lock/unlock door locks 2, 4 and 5 to wake them up when the reorganization process gets to these devices. In addition, having door locks 8 and 9 not working will cause error messages in the reorganization process, so it would be good to either remove these devices from Z-Wave or re-install the batteries so the door locks are working again. Having a "clean" and correct reorganization (i.e., getting a good routing table and neighbor list) should create a reliable Z-Wave network. If you see an unusual/incorrect/inefficient path in the routing table, you can manually add a route.

Once the reorganization process is completed (you can watch the Job Queue for progress), generate Z-Wave communication to every device and verify packet delivery is 100% and timing is good. The Zniffer history will report how individual packets are routed. You can also see this information on the route map by hovering the house over a device (for example, hover the mouse over device 27 and look on the right side info panel of the route map). My route map is shown below where my mouse is hovered over device 12 with the routing info for device 12 appearing in the red square.
route map-annotated.jpg
route map-annotated.jpg (64.64 KiB) Viewed 7607 times
The goal is to have 100% delivery rate with 0% rerouting, and definitely no explorer frames. Note that the routing stats data will only be reported when you have traffic (i.e., the number of packets must be greater than 0). This is why you need to generate Z-Wave communication to every device.
User avatar
marco
Posts: 85
Joined: 03 Dec 2015 19:50

Re: DanalockBTZE100Square status report issue

Post by marco »

Assuming the routing problem exists as you say, I should have problems sending commands to the locks. That doesn't happen. Every time I send the command they receive it. The state of the widget remains random though. Plus lock interviews happen up to 100% from that position.
The wall you highlight is actually made of plasterboard so no metal plate can shade the devices and then there is no problem with nodes 26,25, 32, and 27.
I can also try to move the controller where you pointed at but with these premises do you think it's effective to solve the status problem? Certainly, the communication with battery-operated devices would improve but I doubt that the problem will be solved also because with the previous version of Zway it had never been encountered.

Moreover, I noted the strange behavior with Fibaro devices.

I'll run a reorganization anyway.
Marco
Post Reply