Again as already mentioned, that depends on whether or not the manufacturer has specifically tuned the physical antenna design to a specific frequency range to achieve optimal region performance or not for that product part number.
Please also note that we are only talking about changring RF region the new Z-Wave 700 series (Z-Wave Gen7) controllers and not any older Z-Wave 500 series (Z-Wave Gen5) controllers, as changing RF region is only possible on a Z-Wave Gen7 controller (and will never work on Z-Wave Gen 7 as they have their RF region hardcoded via SAW filter in their SoC chip, which Gen7 SoC does not).
Some manufacturers which use integrated antennas on the PCB board will do so to achieve best performance, but if you use a hardware design with SMA-connector for an external antenna for instead then can use the same Z-Wave 700 controller module and only replace the external antenna.
Aeotec already noted that they are using antenna designs tuned for each region for Aeotec Z-Stick 7 and therefore each region have its own unique part number of that product.
However, Silabs UZB-7 reference USB stick hardware uses the same antenna design and part number worldwide, meaning that it probably does not have an antenna design that has been specifically tuned for a specific RF region.
The lead developer of Z-Wave JS (which the Home Assistant uses now) have tested this himself on Silabs UZB-7 and he was the one who added RF region changing to Z-Wave JS, see:
Again, the RF region is not locked in firmware for Z-Wave 700 series and can be changed via software on all and any Silabs Z-Wave 700 series chip, that is a fact, and if you have an adapter which a physical antenna design that is not specifically tuned for an as limited frequency range then you can just change the RF region.
I’d like an official source from SiLabs or Aeotec on this statement. Until then, if you want to risk bricking your ZStick by updating a firmware not designed for the region the stick was sold for, be my guest.
Thought I made it clear that it does not apply to Aeotec Z-Stick 7 since they do have different parts with antennas tuned for US and EU RF regions and thus you should use those in the region it was made for.
It do however apply to Silabs UZB-7 / SLUSB7000A which only has one worldwide part = SLUSB001A.
It also applies to products based on the ZGM130S Z-Wave 700 Series SiP module for which you notice that there are not no region specific parts, instead ZGM130S037HGN is the only part number there:
This Silabs UZB-7 board and the Z-Wave 700 Series SiP modules contains SAW filters for three common frequency ranges, (see BOM yourself), and those three RF regions are range blocks defined to cover the global Z-Wave frequency range.
This is the only relevant part of your post and it is good to know that it works with this specific stick. Everything else is completely irrelevant for an enduser device like the Aeotec zstick, as RF region enforcement can be done by the manufacturer firmware for certification reasons, as I mentioned in my post and you conveniently ignored. We’re not talking about someone purchasing bulk zwave chips from Silabs, manufacturing their own stick with their own firmware and having it certified by Silabs.
So back to the actual subject, shall we ? Do you have any authoritative source confirming your earlier statement that flashing the ‘wrong’ firmware onto an Aeotec ZStick 7 will work to change RF regions ? While this would indeed be very useful in the light of the current chip shortage situation, this is indeed a pretty bold claim, as it could lead to sticks getting bricked if people actually do it and it ends up being unsupported:
I do not see Aeotec claiming that this would work. I did see they mentioned that doing this on a Gen5 would brick the stick for legal reasons (amongst others, like Gen5 HW limitations). Did I miss the part where they say that this is fine on a Gen7 stick ?
No, you are hung up on Aeotec Z-Stick 7 specifically and that is not relevant for this specific thread as the questions lifted about the Home Assistant Amber was wheater or not they could sell the same worldwide part for a Z-Wave radio for or with the Amber. The answer to that is yes you can now have one worldwide part with Z-Wave 700 series chips and that is what is relevant for this thread.
You are getting off-topic when making this only about Aeotec Z-Stick 7 as this is not a support thread about that specific product. Please feel free to start a new thread about flashing firmware on a specific product that is not directly related to the Amber.
I wrote that you could BUT you must have missied or ignored that I also wrote more than once that you SHOUD NOT do so on Aeotec Z-Stick 7 because their dongles made for each region have an antenna that are tuned foronly a specific frequency range, so if you do so anyway then it will not perform as well as the manufacturer designed it.
It is however not bold to say that flashing the wrong application firmware will not brick it since you only flash the application firmware and leave the bootloader firmware alone. That is similar to how installing a new operatingsystem to your computer can not brick it because it does not flash a new BIOS/UEFI. As long as the bootloader is intact you will be able to recover by manually reflashing the application again via serial commands.
If someone want to flash Aeotec Z-Stick 7 with other region firmware anyway despite the recommendations against it then they should be aware that the Z-Wave Tool in Simplicity Studio only allow flashing a newer version of firmware, so if want to flash back then need to a newer version of that or risk having to wait until Silabs releases a new version.
From where do you source that it would work but with decreased performance, rather than, you know, make your stick permanently unusable as it would be for a Gen5 stick (and as Aeotec has said themselves) ?
You have no idea about that. Did you write the firmware for it ? Do you have access to the source ? Did an Aeotec engineer who would actually knows (rather than simply hypothesizing like you) confirm that to you in some way ? There’s myriads of other ways to brick an embedded device even with bootloader intact and reflashing them might not be trivial at all for a non technical user. Source : I’m a software engineer and I do that for a living.
Anyway this is offtopic indeed and leading to nowhere. You talk a lot, but it’s all hypothetical. I don’t see you personally replacing the sticks of people who follow your claim and then brick them in the process. So if I were you, unless you have substancial and authoritative evidence that this is supported, I’d edit my post above and remove the claim that changing RF regions by flashing the wrong firmware against Aeotecs advice ‘would work’. But that’s just me. Have a nice day.
It looks like a great package but: agreed, with a system that uses a reasonable amount of local sensing hardware, I’m using I2C, 1-wire, Digital control as well as serial/USB currently so would like to see broader range of interfaces.
The Zigbee module can be firmware updated to handle the new Matter protocol. - If done, does it still work at the same time with old ZigBee devices?
The Rpi4 CM comes in a lot of versions. Since Amber can use a M.2 slot for SSD, does Amber then need or use the eMMC-memory, - so a CM-board with zero eMMC can be used?
It is already confirmed it will work, since Matter is built on Thread, and it is an OpenThread certified radio in the device, Matter is just a software stack on top of that, which can run as an addon or in a container if not using HASSOS.
If you use an SSD, you can indeed use a flashless CM4
That was not the question. Will Matter and Zigbee coexist on the same radio ? The CC2652 runs both Thread and Zigbee, but you have to flash either a Thread stack or a Zigbee stack for the moment.
Nice to know! This means you need to use one of the USB ports for a Matter-USB-dongle (or Zigbee-USB-dongle) if you want to keep your existing Zigbee network and use upcoming Matter devices.
I also have a Z-Wave network using the second USB port. Which for me means I don’t have any spare USB port for other protocols (443MhZ-dongle or GSM-dongle…).
Unfortunately for me, Amber then lacks two USB ports. It should have had four USB ports for forward flexibility.
Matter/Thread is not out, no one would know for certain on what that would look like, or how the development would go after launch.
Also, if Matter/Thread in the end does requires a separate dongle so that to run a different mesh than zigbee, I will call the initiative a total failure right there.
After years of cooking and confusing name changes, requiring a different dongle would be (very, very, very,) far from the “unifying the IoT segmentation” idea that the CHIP/Thread/Matter initiative promised from the beginning.
Thread is out, and has been for a while. Matter is built on top of Thread or other ipv6 network connections, Zigbee is NOT an ipv6 network protocol, which is why you have to flash either a Thread or Zigbee stack to the radio, but cannot do both.
Matter is more akin to HTTP, wheras Thread is more like TCP/IP, Matter is just another protocol layer on top of Thread.
Will there be radios that can do Zigbee and Thread at the same time? Maybe, but I do not believe they currently exist. What would be more interesting is being able to flash newer Zigbee devices to run on Matter/Thread
Oh wow. Cool. I learned a bit more today. Thanks a ton!.
Looks like the soup of letters makes the whole thing even more confusing… So Thread and Zigbee (and BLE?) are all competing?, but Matter wants to unite them all? Is that more or less the idea?
So back to the problem statement of fewer USB ports than expected in Tomahawk’s use case: I suppose a quick USB hub is also a (less elegant, but still a) solution.