Lixee Firmware Choice

[SilentT-FR]

https://github.com/Koenkk/zigbee-herdsman-converters/blob/master/lib/ota/lixee.js

@arenoux

@vk496

I think we can add a feature to have the choice the Firmware route or not route : https://github.com/fairecasoimeme/Zlinky_TIC#route-or-not-route-from-v7 and/or how to change between them in z2m

[arenoux]

Do you already have devices with this kind of choice (choose something else than the last firmware available) ?

[Hedda]

@fairecasoimeme What are the reason(s) why your "LiXee ZLinky_TIC" device has two different Zigbee Router firmware images with one having Zigbee routing enabled and the other having Zigbee routing disabled while still being a Zigbee Router firmware?

https://www.zigbee2mqtt.io/devices/ZLinky_TIC.html

https://lixee.fr/produits/37-zigate-usb-ttl-3770014375148.html

https://github.com/fairecasoimeme/Zlinky_TIC

https://github.com/fairecasoimeme/Zlinky_TIC/releases

Should the "no route" firmware alternative in that case not be a Zigbee End Device firmware instead and have that firmware variant use a different "Zigbee Device Signature" so that the device signatures for the two different firmware are confused?

That way it would in practice make it two different devices depending on which firmware was manually pre-flashed on it so OTA would work without issues and the user should manually re-flash the device if they want to switch to the other firmware variant.

[SilentT-FR]

you have a french explication here :

https://github.com/fairecasoimeme/Zlinky_TIC/blob/master/README.md#route-or-not-route-from-v7

This device was powered by a limited powersupply a French electric meter https://www.enedis.fr/media/2035/download Page 7 : 130 mW

The routing function consumes energy (transmission / reception packets) and on a big network the Lixee become not electric stable

a no_router version has been developed in order to limit the traffic of other devices, process on the Lixee.

[SilentT-FR]

And you can see user use tricky method to OTA in no_router mode

https://github.com/fairecasoimeme/Zlinky_TIC/issues/110 https://github.com/fairecasoimeme/Zlinky_TIC/issues/89#issuecomment-1236422701

[Hedda]

you have a french explication here :

https://github.com/fairecasoimeme/Zlinky_TIC/blob/master/README.md#route-or-not-route-from-v7

This device was powered by a limited powersupply a French electric meter https://www.enedis.fr/media/2035/download Page 7 : 130 mW

The routing function consumes energy (transmission / reception packets) and the Lixee is not electric stable

a no_router version has been developed in order to limit the traffic of other devices on the Zlinky_TIC.

That sounds very hacky. Why not only make just a Zigbee End Device firmware for it and no other firmware variants? I mean not make any Zigbee Router firmware for it. Why does it even need to be a Zigbee Router at all?

https://www.zigbee2mqtt.io/advanced/zigbee/01_zigbee_network.html#device-types

Sounds as a perfect use case for ”Zigbee End Device” (ZED), and a bad use case for making it a Zigbee Router (ZR).

Zigbee End Device can also be mains-powered instead of battery powered even if that is not as common, so it does not have to have Zigbee Router firmware just because it is not battery operated.

For example, most mains-powered Zigbee switch module devices without neutral will have Zigbee End Device (ZED) firmware for the reason that without neutral their power is not totally reliable even though they are mains-powered.

[SilentT-FR]

Its a ZRouter because its not a battery devices and in fact its was from the beginning a ZRouter device.

It is only after some user encounters problems, (untimely restart of the lixee), because our electric meters which are manufactured by several brands and therefore are more or less capable of making 130 mW, that why a no router mode has been developed. which is only the same firmware with just the non-routing possibility

The Lixee can be on the center of the house (depending of where is the eletric meter), so it can be a good router position, but is it possible in certain condition to support ZRouter so why removing that after

[Hedda]

Still, bad original choice then to make it Zigbee Router instead of Zigbee End Device. Better way forward could still be to just release a Zigbee End Device firmware for it and withdraw the Zigbee Router firmware option.

[SilentT-FR]

i have worked on code

@vk496 @arenoux

https://github.com/Koenkk/zigbee-herdsman-converters/compare/master...SilentT-FR:zigbee-herdsman-converters:lixee_firmware

Im not sure about : https://github.com/SilentT-FR/zigbee-herdsman-converters/blob/lixee_firmware/lib/ota/lixee.js#L14

the path to retrieve the variable device.options.zigbee_mode

[vk496]

I like your approach. It's more simple that what is done with IKEA test servers. But I would definitely simplify the code or it will be really hard to read in the future.

Moreover, I'm not sure that if the user switch from one mode to other, he will get the ability to update the firmware. Or you already tested it?

BR, Valentín

[SilentT-FR]

Moreover, I'm not sure that if the user switch from one mode to other, he will get the ability to update the firmware. Or you already tested it?

Not tested, but it won't work, because it only compares the version it only works when a new version is available, I don't know if the lixee inform z2m the current firmware mode

[SilentT-FR]

I like your approach. It's more simple that what is done with IKEA test servers.

i think its because IKEA have multiple devices so its global config but yes we cannot configure ikea devices one by one

[vk496]

@SilentT-FR I checked your code more in detail and it would not pass because of syntax errors.

I was thinking about how to deal with users of different versions and different states (I just want to update or Im last version and want to change the behaviour).

Since the firmware is published without any structure and it .ota name could potentially change in the future, I think the best way is to store a string in the configuration and then use it as direct path to URL .ota file. So by default it will still get the last version but if user overrides it with a URL, it will use that URL directly.

The option for the user shall be exposed as Composite I think. So or is disabled or it have a URL. What do you think?

BR, Valentin

[Hedda]

FYI, @fairecasoimeme mentioned three days ago in ZLinky quirk discussion for ZHA Device Handlers that he is currently thinking about handling route / non-route OTA firmware for this same device in some different way, I assume that he means adding additional attributes to future firmware revisions or some other additional configuration changes in future firmware for this device.

Originally posted by @fairecasoimeme in https://github.com/zigpy/zha-device-handlers/issues/1146#issuecomment-1280897613

I think I'll use a different way to manage route / non-route OTA firmware. Don't hesitate to give suggestions to be easier for OTA plugins ;)

[vk496]

Thank you @Hedda. Having some tag inside firmware image would be the best way for sure. Relying on names that are not provided through CI/CD is a bad idea for sure. I think waiting is the best decision right now.

[fairecasoimeme]

Still, bad original choice then to make it Zigbee Router instead of Zigbee End Device. Better way forward could still be to just release a Zigbee End Device firmware for it and withdraw the Zigbee Router firmware option.

The no_route version is a bad name because since version 7, the no_route version is rather a limitation of the management of the routing of the children to 1 only. I don't do ZED because this mode requires sleep loop, which is not suited to the product.

[fairecasoimeme]

I think I'll play with OTA header attribute to differentiate the 2 versions. like (Image type or header Str for example)

[Hedda]

Could otherwise just use two different Zigbee Device Signature so that they would be seen as not using the exact same device ID.

[Hedda]

Sorry for crossposting the question, but FYI, for reference,, there is also a related discussion for zigpy here -> https://github.com/zigpy/zigpy/issues/1060

Obviously the request related specifically to zigpy does not belong here however just wanted to inform that it is not only zigbee-herdsman based implementation that faces this same dilemma when it comes to writing OTA provider download code when it comes to a product that offers two alternative firmware images variants to pre-configure the same device via flashing.

Having different alternative firmware image variants works if only offers manual flashing but it does not work if OTA is an option.

IMHO there really needs to be only one unified OTA firmware image for it and then that can be configured differently afterwards.

[vk496]

I personally don't see any issue regarding the OTA and 2 firmwares. The current behavior in Z2M is to get the last release and take the first .ota file as update. If the headers of that ota match the device and are different in version, OTA popups for the user.

If @fairecasoimeme will continue putting the releases as it does until now (first ZRD then ZED), it will work for people with the current implementation as usual.

And after putting the hint in the images headers, a user will be able to change the default behavior from specific options and reflash as OTA update.

[fairecasoimeme]

Yes, I think I will make an official version with full routing functionality for children with a classic OTA header and later a version with a light routing functionality with another OTA header to avoid errors of update.

By default, ZLinky will be flashed with the official version. If a user wants to upgrade to the light version, the first flash will have to be done with the usb TTL module.

[pipiche38]

Going via the USB TTL module makes indeed sense and will create 2 products with 2 image type.

[MattWestb]

I think the 2 different OTA images with different image ID is the right way to go !! Also standard (original shipped firmware) is working with normal OTA for all user. And then the user have "converting" to the "light router" firmware the OTA is working OK and shall not having any problem in the future.

Only problem if its easy enough changing firmware type with USB-TTL adapter.

The optimal way is dual function firmware with working mode change by Zigbee commands and dont need different firmware types being loaded on the device but its much work implanting and testing it.

One way is making 2 "converting firmware". One with standard firmware ID in the OTA header and is having the light router ID in the firmware then its being flashed >its requesting the light router firmware after the converting OTA. And one that is doing the opposite: Light router image ID header and router firmware in the OTA file.

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days