[REQUEST] TL reset funktionality.
MattWestb opened this issue · 5 comments
My experience of "removing" ZB3 bulbs that is working in real ZB3 mode is listening to the leav command but don't going in pairing mode and ending up in being in "Touch link modoe" and waiting for touch link initiating and not responding on "hardware reset" (6*on / off for IKEA) at all .
Both in deCONZ and Z2M users having problem that "hard" reset is not working on bulbs (most IKEA ZB3 but also others) and cant pairing devices (Its one firmware bug for 110%).
I have 2 times must using deCONZ with the old "webapp" for doing touch link reset of the bulb (and one time one wrong one in the kitchen 6 meters away). Then version 2 of RaspBee and CornBee have not the touch link implanted in the firmware its not possible for all user doing it.
Then all "normal" EZSP firmware have support for it so i was trying the Hue Thief that have working very well for some users. The problem its that the python 3.6 have broken some functionality and its not possible getting it to working. And the python 3.7 its possible getting the radio scanning working but not the consolle in/output (change in 3.7) is broken so its one dead end.
Was looking little and its one very small code that is used but the most is using one old (7.0) bellows for doing the hardware access (its working with newer bellows also if forcing updating it but not the last beta). Then I don't have the knowledge and experience of programming python i cant fixing it and making it working.
Then the most code is already in the "zigpy" (bellows) and the footprint is very small (300 lines) and the benefits large i suggesting that implanting it in the ZHA_CUSTOM as one more "service".
I don't knowing if more radios have support for it in the standard firmware (TI and dresden have it partly) so its not really belonging in ZHAs core.
If not possible putting it in ZHA_CUSTOM as service is still possible forking it and making one own project in zigpy and updating the code to py6.7/6.8 and using the installed bellows. That is making it useful for our user that getting device reset problems.
One other option is implanting it in zigpy / ZHA for more radio platforms and making one nice GUI in ZHA as deCONZ old "webbapp" and Z2M brand new front have with scanning, getting device list, Identify (blink) device and resetting device.
If i was having the knowledge of coding python i was having fixing it but sadly i don't have that.
Pleas taking one look and see if you can do some of it for zigpy or standalone installation.
Thanks in advance and also for all the work you have putting in bellows.
Does itead t happen with any Ikea bulb? What a the steps to reproduce? Gonna be in Ikea today, could grab one of the bulbs to test
Recommending the cheap "family pack" with one WW bulb and one On/Off dimmer switch its cheep in EU 9€ (13$ in US) if you dont going for some more expensive. (was buying 3 of this and all the bulbs is "converted" to BIlly EZSP modules)
I was buying 2 sets of 3x GU10 WS (not in US) with the remote not cheap (40 €) but working well (If not fixing them and they is falling on the ground and braking).
First time it was happening with one GU10 WS (its the new glas one with color temperature) pared OK in ZHA with bellows but I was liking doing the binding and groups new but was not working as i would like (the coordinator assigned group was not being added).
Then deleting the bulb and it was leaving and blinking one time. Was doing other things and some minute later trying pairing = not in pairing mode. Pepower = not in pairing mode. Power on / off 6 time = not working. The last was around 10 times without success.
The bulb have timing out its first pairing mode and have forming one own network (find and bind i think its the name) but is not taking the "hardware" reset. 110% one firmware bug then the "hardware reset" should also working in this mode.
Touchlink reset from deCONZ (old web app) was finding it (blinking) and possible resetting it and then pairing in ZHA.
Next time was one old IKEA E27 opal 1000lm (LL not ZB3) removed from deCONZ and paired in ZHA with one CC-2531. Deleting in and it was leaving and confirming with blinking.
The same as the first time.
One warning if you have one RaspBee or CorBee II its dont have the Techlink implemented in the firmware so only working on the first generation (I think its no great problem for you using bellows for doing the TL-reset).
One things with IKEA bulbs is that they normally sharing the same firmware but have different name / parameters in the data settings (Memory airia 1 = user data = not being erased by internal flash erase). I was putting the Board and MFT tokin in the userdata with hex editing as you was remember.
If you have one On/Off switch its the same HW and SW as the open / close one only different data settings.
Second warning: IKEA is very expensive then you normally buying 2 mutch things then you is being there !!!!
I hope you have coming back from IKEA with not toooo much things in the baggage (Like one new kitchen with integrated Zigbee lights) !!!
I was thinking little after reading and its normal for LL and touchlink ZB3 lights after being reseted and timing out they normally starting one network with pan-ID 0x0fffe (default LL) and waiting for beacon broadcast for joining one network. The problem can being that the NCP was having channles 15. 20 and 25 and not 11 in the channel list. If the bulb was on channel 11 then the NCP was not broadcasting beacon on channel 11 and was not finding the bulb. But NCP suld trying the secondary channels if its not finding one devices fo pairing on the primary ones (secondary channels = all no primary ones if i remember right).
I can testing it later then i redoing the test install and "sniffing" the channel and PAN-ID from deCONZ old web app.
Perhaps its not one firmware bug only one false logic thinking.
I was having wrong i most cases :-(
Was deleting the old E27 WW (LL) in ZHA with CC2531.
It was NOT confirming leaving with blinking.
In deCONZ with touchlink I can see it have left and being on channel 25 with random PAN-ID.
Then the nightmare: deCONZ is joining it without having it open for joining (was before in deCONZ but deleted = its known there and its not being deleted in the DB and dont sending one real leave command that is resetting the device to factory new).
In deCONZ GUI. Deleting = its rejoning, deleting = its rejoining . . . . .. . . . . .. .. . . . .. . . .. . .
Taking deCONZ down for updating it and updating the RapBee firmware. power of and disconnecting power and starting with one new updated deCONZ.
I have disabled autostart and was deleting some devices that i have removed and is using in ZHA.
Starting deCONZ and must repower the HUE bulbs but the IKEA is working out of the box with source routing and all Xaoimi sensors looks working but deCONZ GUI dont knowing where they are (they are not in the GUI but is sending data).
Enough of deCONZ now !!
Was resetting the IKEA bulb with on/off and its was on channel 25 with random PAN-ID.
Pairing in ZHA and its going in OK.
Deleting it in ZHA and its leaving nice without confirming with blinking.
Its being on channel 20 with random PAN-ID.
Trying pairing in ZHA its not working, Repower the bulb and its on channel 20 with one new PAN-ID and pairing OK.
Deleting in ZHA its leaving and being on channel 20 with one new random PAN-ID.
Repower and ch 20 and new pan. Repower and ch 20 and new pan. Repower and ch 11 and new pan.
Pairing it with OK in ZHA (I have putting channel 11 on the channels list in my config).
Its looks that after being reseted its taking one random ch and pan (the power off on after reset its normal for IKEA after reset for being possible pairing it in "classical" (no TL) pairing mode) and its changing them after every repower then not having any networks tokens in the flash.
I think my first problems was that the bulbs was resident on channel 11 after repower in combination with not having ch 11 in the channels list and perhaps deCONZ was doing some "magic things".
I have not testing with ch 11 omitted in the list but its very likely making some problems if the device is "parking" there then being reseted and ZHA cant finding it.
Now i knowing its only repower the bulb and its coming back on one random (LL) channel so only trying some time and it sould working.
One short update: I have trying helping some users that have problem pairing IKEA E12/E14 bulbs that don't like being reseted. On is having one small family pack (bulb with 2B remote) that was paired from factory. After some days of trying resetting the bulb its still reacting on commands from the remote = it still have the original network credential and reset was not successful. The user cant do touchlink reset then the NCP don't have it implanted (CornBee II).
My conclusion is that some IKEA and perhaps other is not always so easy getting the reset function to working for the user and also it can being that the light is being reseted but have timing out pairing mode and making its own "local LL network" and its not easy getting back to "factory new" and getting paired in "classical joining".
TL reset can making it easier for the user the light in factory new state and joining the network.
One / 2 more touchlink function that have popping up: Sending network parameters to one device (the network crdeshials and then the TC is finding it then it doing one device announcement and can initiating it) also can helping if have losing one device after network changes.
One IKEA speciale: Sending group to end devices that the IKEA GW is doing the setting them up.
The commands is normal zigbee commands but can only being sended thru touchlink.
This making the special scene control buttons being configured to custom groupe ( its being locked to 0xff09 in the firmware if not being setted up with TL).
I think also it can helping user with IKEA blinds sending the groupe to the signal repeater so it can acting as one relay for the blinds commands from the remote and the blinds.
It can being that its helping more IKEA controlling devices to function better then the normal binding looks working OK but some "magic" things can being broken then the device dont have getting one groupe then its being initialised (groupe cant being setted with normal zigbee command as i mented abow if some cluster is missing in the device that it sending command from "ala IKEA").
I think both functions it possible implanting in zigpy for NCPs that supporting TL without very much work but as normal thinking is not knowing :-((
The next is not intended for Zigpy only as brainstorming but i knowing you is interesting of "impossible" things ;-)
I knowing one very nice device type that is working with all above scenarios but no one have interesting putting time to coding it.
Its one in zigbee standard its the "controlling bridge". More or less one router that is setted as dynamic and can talking with all devices in the network and sending / receiving commands in LL network and also possible with TC networks. Its the working mode IKEAs GW is using plus IKEA have implanting configuration of the LL network parameters thru touchlink like address range and group range for controlling devices (is not one TC but is doing the administration of the network layout) that is not needed / wanted then we is using TC .
What i like with the concept is that having one large light network that working as normal but dont using all the HA things for doing magic and making problems then HA is down or having problems.
One example: In bath one motion sensor that is sending on with off 60. Its automome. If like over ride it then taking one shower you need making HA automations that is deepening of HA and other system being online (also the WiFI). Then having one "controller bridge" getting one command from one long press from one switch its start sending On with off 60 every 50 seconds to the light groupe until getting one short press from the switch. Both is autonome and is working without WiFi (tasmota can having trouble without WiFi) and other upper systems.
That is very easy being done in tasmota or other small devices if having implating the CLI for the controlling bridge in tasmota. For tasmota its opening for implanting OTA and other functions that is not possible having the the zigbee bridge then its not enough with flash / ram in the ESP.
It also can doing OTA upgrades on IKEA or HUE network for devices that is not supported by the GW like OSRAM devices and so on.
Stephan H have done all thing hi like to do on tasmoat zigbee bridge but hi dont like / cant implanting OTA and touchlink in the Zigbee bridge (too less flash and ram). Perhaps hi is getting time end energy to doing one "zigbee controlling bridge" for tasmota with OTA. Touchlink reset / network init / group config and dynamic autonome controlling of devices in one large zigbee network plus wireshark sniffing.