zwave-js-ui
zwave-js-ui copied to clipboard
zwave-js
RF Region for firmware updates not set correctly when a controller that doesn't support RF Region is used.
Checklist
- [x] I am not using Home Assistant. Or: a developer has told me to come here.
- [x] I have checked the troubleshooting section and my problem is not described there.
- [x] I have read the changelog and my problem is not mentioned there.
Deploy method
Docker
Z-Wave JS UI version
10.5.0
ZwaveJS version
15.4.1
Describe the bug
As described in #4233 and partially fixed in #4235 When a controller is used that does not allow setting of an RF Region, a default RF Region is selected on devices that may not correspond to the area in which the device is used.
To Reproduce
- Use a controller such as an Aeotec Gen 5 stick that does not support setting RF region.
- navigate to a device that has regional firmware and attempt to update the device. Notice that the RF Region shows as defaulted to EU, but in reality is actually null. No available firmware will be presented because of the null region being passed.
2025-05-13 22:18:27.080 INFO Z-WAVE: Calling api getAvailableFirmwareUpdates with args: [ 57, { includePrereleases: false, rfRegion: null }, [length]: 2 ]
- Change to your actual region and query for an update. It will actually find the correct firmware now.
2025-05-13 22:18:43.149 INFO Z-WAVE: Calling api getAvailableFirmwareUpdates with args: [ 57, { includePrereleases: false, rfRegion: 1 }, [length]: 2 ]
2025-05-13 22:18:43.553 INFO Z-WAVE: Success zwave api call getAvailableFirmwareUpdates [
{
device: {
manufacturerId: 634,
productType: 28672,
productId: 40967,
firmwareVersion: '4.30.0',
rfRegion: 1
},
version: '4.50.0',
changelog: 'Includes firmware versions: 4.10, 4.20, 4.30, 4.40, 4.50.\n' +
'* Fixed the Range Test Tool feature.\n' +
'* Added a new parameter 33: Convert the dimmer to a switch.',
channel: 'stable',
region: 'usa',
files: [
{
target: 0,
integrity: 'sha256:ff6ea11f5718ebe6fb8bac1a1183ebe15d70f059dac9a44b60a0b67f36ae8bb9',
url: 'https://www.getzooz.com/firmware/ZEN77_V04R50.gbl'
},
[length]: 1
],
downgrade: false,
normalizedVersion: '4.50.0'
},
{
device: {
manufacturerId: 634,
productType: 28672,
productId: 40967,
firmwareVersion: '4.30.0',
rfRegion: 1
},
version: '4.60.0',
changelog: 'Includes firmware versions: 4.10, 4.20, 4.30, 4.40, 4.50, 4.60.\n' +
'* Updated parameter names and short descriptions in the Configuration Command Class.\n' +
'* Added a new parameter 34: Basic Set Custom Brightness On.',
channel: 'stable',
region: 'usa',
files: [
{
target: 0,
integrity: 'sha256:b4b91fdc75e3ac08c4c01a53f9d795e3f2d12c11fd6f40678d51134c2c88c342',
url: 'https://www.getzooz.com/firmware/ZEN77_V04R60.gbl'
},
[length]: 1
],
downgrade: false,
normalizedVersion: '4.60.0'
},
[length]: 2
]
Expected behavior
Having to manually set a region for every OTA updates seems to be a casualty of ZJS using the set value of the controller region for this value. For controllers that don't support setting this value, the region ends up being null. I suggest a global config value that is exposed for controllers where rfRegion == undefined and allows the setting of rfRegion as it pertains to the OTA updates.
Additional context
Discussion #4233
@swstraus what about storing the rfRegion selected there on local storage by default? cc @AlCalzone ?
what about storing the rfRegion selected there on local storage by default?
rfRegion selected where? In the device itself? It seems a bit onerous to have to go do that for every device and on each new device added. I can't envision a use case where devices would need that set uniquely. If you mean just having the value be global and stored locally in a config file, that seems fine. Are you talking about store/settings.json? Something to take into account would be if someone upgrades from a stick that doesn't support setting rfRegion being set to one that does, this setting would probably need to be removed or not used.
Selecting rf region in the ota update stores the rfregion on browser local storage and of course that is applied for that input on each device
What if something is querying via the api?
What do you mean? Anyway the alternative is to use the settings "Default RF region" when it is set. That setting already exists
What do you mean?
It is my understanding after chatting with freshcoast that HA and other things like it query firmware update via the ZJS api. If that's not the case, then I'm mistaken.
Anyway the alternative is to use the settings "Default RF region" when it is set. That setting already exists
Global Default RF Region currently defaults to "null" when I have a controller where I cannot set that value. Where am I able to set that setting globally for all devices?
2025-05-13 22:18:27.080 INFO Z-WAVE: Calling api getAvailableFirmwareUpdates with args: [ 57, { includePrereleases: false, rfRegion: null }, [length]: 2 ]
Sorry if I'm being obtuse here.
@swstraus I'm discussing about this with @AlCalzone , we actually have 2 proposal we will ask in a poll on Discord
like it query firmware update via the ZJS api
Z-Wave JS UI only hosts the Z-Wave JS Server, which provides direct access to the API of the Z-Wave JS driver that Z-Wave JS UI also uses. It does not matter what you configure in Z-Wave JS UI, because it won't carry over to whatever is being done via Z-Wave JS Server.
A similar functionality would also have to be implemented in HA if you want to perform the updates from there.
Thanks to both of you for your time. I guess one thing at a time here. I installed a new device yesterday that needed a firmware update (that was not region specific) and it showed up in HA when ZJSUI showed there was an update. My impression after chatting with others was that ZJS server was doing the heavy lifting here because of that. It appeared as if ZJS (driver?) was applying the update and HA was simply reporting the progress.
In which server and channel are you going to host the poll?
This might have just been a coincidence. Both Z-Wave JS UI and HA instruct zwave-js (the driver) to check for updates, only that Z-Wave JS UI will call the driver API directly, and HA has to go through the websocket server.
In which server and channel are you going to host the poll?
The Z-Wave JS Discord server, in the general channel
No, I thought you wanted to do that 😇
Anyways I've thought about this in a different context recently. My idea is to make the (default) RF region setting required. This will avoid confusion when migrating between different controllers set to a different region. And even if the controller does not support querying or setting the region, it can then act as the fallback region for firmware updates.
No, I thought you wanted to do that 😇
I think we spoke about it on a PM then I completely forgot, sorry
My idea is to make the (default) RF region setting required. This will avoid confusion when migrating between different controllers set to a different region. And even if the controller does not support querying or setting the region, it can then act as the fallback region for firmware updates.
Agree 👍🏼
I went ahead and updated to the latest container with changes from #4277 and #4278 and everything appears to work as intended. THANK YOU. I'm not sure if this is a side effect of the config being updated for default regions, but HA now shows a bunch of warnings about re-interviewing nodes. Not a big deal, but people will probably report this.
That's actually unrelated. I changed lots and lots of labels and and instructions a while ago, and until the last update those were included when determining whether device configurations were changed. Going forward that should not happen anymore.