3.0.6 - Priority routing

[anom3]

So I have just made the upgrade from 2.3.8 to 3.0.6.

I see that priority routing is sort of in place now. Nice... This has made my Controller -> Device connections MUCH more stable... Multi floor hops at 100kb, sub 100ms transfers pretty much every time.

I am now trying to get the return paths working...

When I try to add them (using the Expert GUI OR directly via the URL) they are accepted by z-way-server, but the just time out.

I checked the debug log, the callback returns 0x00...

Why is that? Does the target device have to be at 6.71 or higher?

Even when I try some of my newer devices using 6.71 (eg: Eurotronic radiator valves), they still timeout...

Is this an issue with z-way-server or am I not understanding things (quite possible!)...

Thanks!

[PoltoS]

Please show the log to help us understand what times out

[anom3]

A) Note : I have 2 UZB controllers running two networks. They are fairly far away from each other... Yes I know I really should combine them, but have not had the time to reinclude everything... Just noting this...

B) I noticed yesterday when I did an update on my "2nd network" from 5.23 to 5.33 that it works fine on the controller.

C) The issue is on the following versions:

SDK Version: 6.71.01
Serial API Version: 05.27
Version number: v3.0.6

D) Note : Yesterday I started playing with silabs pc controller... I tried to set the priority return route using their application. It timed out as well Yes I am aware the nodeids have to be in hex. The controller -> device routes I was able to set just fine using their app.

E) IMPORTANT NOTE : Over the years, when I removed a secondary controller... My primary controller some how was switch to Node ID 14. Maybe this is related?

Role in Network
Node Id: 14

F) So, UZB @ Firmware 5.27 + Primary controller nodeid 14 running z-way-server 3.0.6. I suspect this issue is due to 5.27 OR the fact my primary controller is NOT on id 1? Also I have not upgraded this firmware because I read issues upgrading UZB firmware at times... I do not want to risk loosing my controller while I wait for another UZB to be delivered... I will order a 2nd UZB and upgrade to latest firmware in the near future. I took the risk on my '2nd network" because it was running 5.23 and did not have the stats so I could not see if the prio routes were working or not... The upgrade went fine after 2-3 tries.

Here is a dump of a log of me trying to set a prio return route 84 -> 71 -> 70 -> 14 (IGNORE nodeid 32, thats one of my PIRs that was activated when I did the check):

---

[2020-06-17 11:40:52.292] [D] [zway] SETDATA devices.84.data.priorityRoutes.14 = Empty
[2020-06-17 11:40:52.292] [D] [zway] SETDATA devices.84.data.priorityRoutes.14 = int[5]
[2020-06-17 11:40:52.292] [D] [zway] [00] 71
[2020-06-17 11:40:52.292] [D] [zway] [01] 70
[2020-06-17 11:40:52.292] [D] [zway] [02] 0
[2020-06-17 11:40:52.292] [D] [zway] [03] 0
[2020-06-17 11:40:52.292] [D] [zway] [04] 3
[2020-06-17 11:40:52.292] [zway] Saving configuration data to config/zddx/f464d793-DevicesData.xml
[2020-06-17 11:40:52.419] [zway] Adding job: Assigns the route with the highest priority
[2020-06-17 11:40:52.429] [D] [zway] SENDING (cb 0x59): ( 01 0B 00 4F 54 0E 47 46 00 00 03 59 BA )
[2020-06-17 11:40:52.430] [D] [zway] RECEIVED ACK
[2020-06-17 11:40:52.451] [D] [zway] RECEIVED: ( 01 04 01 4F 01 B4 )
[2020-06-17 11:40:52.451] [D] [zway] SENT ACK
[2020-06-17 11:40:52.451] [D] [zway] Delivered to Z-Wave stack: process started
[2020-06-17 11:40:53.972] [D] [zway] RECEIVED: ( 01 0C 00 04 00 20 04 30 03 FF 01 C4 00 DA )
[2020-06-17 11:40:53.973] [D] [zway] SENT ACK
[2020-06-17 11:40:53.973] [D] [zway] SETDATA devices.32.data.lastReceived = 0 (0x00000000)
[2020-06-17 11:40:53.973] [D] [zway] SETDATA devices.32.instances.0.commandClasses.48.data.1.level = True
[2020-06-17 11:40:53.973] [D] [zway] SETDATA devices.32.instances.0.commandClasses.48.data.1 = Empty
[2020-06-17 11:40:54.325] [D] [zway] RECEIVED: ( 01 05 00 4F 00 00 B5 )
[2020-06-17 11:40:54.326] [D] [zway] SENT ACK
[2020-06-17 11:40:54.326] [W] [zway] No job of class 0x4f is waiting for callback 0x00
[2020-06-17 11:40:54.326] [D] [zway] AssignPriorityReturnRoute Response with callback 0x00 received: received by recipient
[2020-06-17 11:40:54.326] [D] [zway] Job 0x4f (Assigns the route with the highest priority): success
[2020-06-17 11:40:54.326] [zway] Removing job: Assigns the route with the highest priority
[2020-06-17 11:41:08.702] [D] [zway] RECEIVED: ( 01 0C 00 04 00 20 04 30 03 FF 01 C4 00 DA )
[2020-06-17 11:41:08.702] [D] [zway] SENT ACK
[2020-06-17 11:41:08.702] [D] [zway] SETDATA devices.32.data.lastReceived = 0 (0x00000000)
[2020-06-17 11:41:08.702] [D] [zway] SETDATA devices.32.instances.0.commandClasses.48.data.1.level = True
[2020-06-17 11:41:08.702] [D] [zway] SETDATA devices.32.instances.0.commandClasses.48.data.1 = Empty
[2020-06-17 11:41:11.924] [D] [zway] Job 0x3b: deleted from queue
[2020-06-17 11:41:12.702] [zway] Job 0x4f (Assigns the route with the highest priority): No callback received before timeout

---

Thank you for the reply... For what its worth... Lots of $$ sent your way over the years 3 razberries, then upgraded to 2 UZBs, plus 9 zuno's running in my PIRs as well as 2 UZB z-way-server licenses

THANKS!

[PoltoS]

Looks like a bug in SDK 6.71 - the answer from the stack is wrong. I think an upgrade to SDK 6.81 will be worth. We are about to release a new SDK 6.82 based version 5.38

[anom3]

Thanks for the info.

As mentioned I am running UZB 5.27 and 5.36 is shown when I use token all.

I see some forum posts about bricking UZB going from 5.27 to 5.36... So I do not want to risk it.

I will order a new UZB stick now just in case and do the upgrade when it arrives so I have something to return to if needed...

Thanks!

[anom3]

Hi!

I can confirm.

My 2nd UZB arrived this morning, so I did the upgrade to 5.36 (6.81.01)... No problems.

Setting priority return routes works fine now The callback is correct now, 0x11.

[2020-06-18 10:07:19.354] [D] [zway] AssignPriorityReturnRoute Response with callback 0x11 received: received by recipient

So yes, its an issue with 6.71.

Thanks!!!