Here it is, in 3 parts.
To make it easier for us, are you having trouble with a particular lamp?
I want to advice to add log cards to each (sun event related) flowcard, so it becomes more clear what does, and what doesn’t work well by reading the logs
I’ve never used Log cards. Are they a standard Homey flow card or is there an App which provides that capability?
| Peter_Kawa Regular
May 12 |
- | - |
I want to advice to add log cards to each (sun event related) flowcard, so it becomes more clear what does, and what doesn’t work well by reading the logs
It’s not so much a particular lamp. It is happening to different devices at different times. Getting TRANSMIT_COMPLETE_FAIL and TRANSMIT_COMPLETE_NO_ACK messages that persist for several minutes and then clear. Mostly associated with Aeotec Smartswitch 6’s.
There is another thread on the forum called Zwave issues with HP23 where a number of people are experiencing similar issues.
In this case I was thinking that maybe the issue was with the size or structure of my AF.
There’s no default log, I’d recommend the Simple Log app.
Yes, that’s not a flow problem, and probably a similar issue as discussed the topic
you mentioned
As @Peter_Kawa und me already said, it’s not a problem of the AF, TRANSMIT_COMPLETE_FAIL and TRANSMIT_COMPLETE_NO_ACK are Z-Wave/HP23 problem.
So I would suggest to contact Athom and Aeotec.
Just out of interest: Would you post a screenshot of the Z-Wave overview?
https://tools.developer.homey.app/tools/zwave
What I want to see is, if there are Unknown NodeID which maybe can cause the problem.
Here it is. I do have some Unknown Nodes but I can’t get rid of them. Would Remove Any Node work. I’ve never tried that as I’m not sure what it does.
Here is a copy of something I wrote to Homey support which describes some weird behaviour I experienced. Basically support tells me I should reset Homey and start again. I am very reluctant to do that, it is a lot of work.
“When I did this yesterday a weird thing happened. I wasn’t able to remove the SS6, the removal screen on the App just stayed blank. But when I went to the devices it was gone. On the developer page I had another Unknown Node but when I sent Basic On/Off commands to the unknown node it did switch the removed device on and off and I can’t remove the unknown node. I have since reset it and it is working OK as Spare 1 again.”
I would suggest try to delete the unknown devices first.
Click on the 3 dots on the right side of the row of the Unknown Node and click on “Remove”.
If “Remove” is greyed out, click first on “Test” (which will fail). After that “Remove” will be available. Click on “Remove”.
Then do a PTP so that the Z-Wave network reorganizes itself. Check if the Unknown Nodes hopefully are gone and check for a few days if the problem is solved.
What is a PTP?
1 Like
Interesting. I’m assuming that PTP for 10 minutes puts the ZWave devices into some kind of state that when Homey comes back up it rebuilds the ZWave network.
I finally got rid of my Unknown Nodes. I just had to persist and refresh the browser after each attempt. Even though I didn’t get a message saying the Node had been removed it eventually was, even though I was getting ZW_FAILED_NODE_NOT_FOUND messages.
After my first PTP one of the Nodes came back so I repeated the process. This time it seems to be gone for good.
Thanks again for your support.
1 Like
I have installed Simple Log. It recommends also installing Better Logic. Is this recommended? I tried to install Better Logic but it keeps timing out after 10000ms.
Explanation why the failing sunset flow is an issue for me. Of course my exact example makes no sense, it is merely to demonstrate the bug.
As explained I use state-based flows, meaning I have a flow responsible for the state of a device. For instance my exterior lights are handled by the flow below:
Below the flow of my waterfall:
The idea is that all these flows can be run at any given time to set their devices in the proper state.
The only thing left is to call all these flows on various events. Below you see my ‘switch all-flow’.
(The number of flows on the right is still small since I am migrating everything to the Pro23)
On my old Homey the list is a bit longer and still in standard flows:
Also in standard flows I have a flow per trigger which is not necessary anymore with AF.
This approach makes bug tracking way more easy compared to having a lot of triggers in a lot of flows. The only thing you have to do is define the state of a (or a few) devices based on the situation and create a flow to handle this.
It immediately removes the need for flows like ‘Switch Everything Off’ and other nasty emergency-flows. Everything is in the proper state, always, after calling the ‘switch-all-flow’, no matter when or why it was called.
Maybe I should write an article about this approach
Regarding ZWave network issues and Unknown Nodes. Here is a copy of an email I sent to Athom Support on the process I followed with your help.
Removing Unknown Nodes:
- Remove Unknown Nodes command
This worked for two of my Unknown Nodes but two remained. It looks like it only removes one node at a time so you need to run it multiple times. It does come back with a Node Removed message when it works but doesn’t say which node was removed.
- Using … at the end of the Node details
This got rid of the remaining two nodes but it isn’t straight forward.
You have to toggle between Heal and Test until the Remove label is active.
There was one occasion where the Test told me the Node was Reachable - weird. On this occasion I kept healing and testing until it showed as unreachable. Then I pressed Remove.
Pressing Remove isn’t always successful. You just need to keep repeating it until you don’t get an error.
I don’t believe that using the remove button gave me a success message, but it didn’t give an error. I had to refresh the page to see if the node was removed. If it wasn’t I repeated the process.
After all Unknown Nodes were removed I then removed power for Homey for 10 minutes. The first time I did this one of the Unknown Nodes came back so I repeated the process. On the next attempt, after powering down the node was gone. They haven’t come back to date.
- Unreachable Nodes
I then went to each node showing as Unreachable and Healed them. Again this often needs to be done multiple times to get a successful outcome. So far all nodes remain reachable but if I get a failure on a device I repeat the Heal process for that node."
The info Unreachable Node is shown when Homey has tried x times (I don’t know the exact number) to reach the device, but the device has not responded.
However, Unreachable Node does not necessarily mean that the device is actually unreachable. From my own experience I can say that in most cases (estimated >= 99%) the devices still work. Therefore I would not pay so much attention to the info Unreachable Node. Battery powered devices need to be woken up before the Test or Heal function, btw.
Observe your system for a while. If there are still problems, it may make sense to install more actuators/repeaters.
Technically it is “not responded in time”.
So if a device doesn’t respond for 3x within the default timeout, it will be flagged “unreachable”.
In theorie it should remove the flag again when the device does responds again, even outside of its timeout, but looks like this sometimes fails.
Though this is getting a bit off topic.
Thank you for the detailed explanation.
OT it is not really, because it became clear relatively quickly that the problem is not the trigger cards for the solar events, but Z-Wave connection problems.
Yes, well that’s the problem when a platform is unstable and issues occur which aren’t easily repeatable, and there is more than one issue. Fault finding is not easy.
And HP23 is still beta. I have spent a lot of time trying to improve the zwave network, and it has improved, but it’s still has some issues. Things are now working about 95%. Sometimes someth8ng just doesn’t switch on. Next time it does.
