Open boelle opened 3 years ago
Just to clarify. I have the samme issue, when I used an original remote. Updated via DIRIGERA, and then joined it to the gateway.
If its one original that is updated with Dirigera its the same status of the device like my updated one. Then i think the manufacture have doing somthing wrong with the data setting in the factory and writing false data in the user data (its not the first time its have happening with the OpenClose and some lights before).
But is the looking OK then pairing it with Dirigera ?
All IKEA controller i have looking on is blocking firmware download so we cant downgrading it also if we was having the OTA file with OTA if we was having it but we can extracting the GBL file and flashing it with SWD (on one unlocked module).
In TF GW i have one remote under sound and 2 shortcut buttons shortcut buttons and you is have getting the last 2 as somthing else that is one normal light controller then the GW have making rooms = Zigbee groups for the 2 extra endpoints for the shortcut buttons. The name and functions of the 2 extra EP is stored in the user data of the device.
I was flashing one module with the files we have used and it was working OK in ZHA. Then paring it with Dirigera and its was start updating the firmware to 1.0.35 so i must sniffing it but if the OTA is being flashed OK we is knowing we have one working set of files
In Dirigera i only getting one remote ad can linking it to Sonoss seekers and not other extra lights or somthing and i still thing you is having strange things in the user data.
I trying getting the new OTA file from sniffing it and reporting back if it going well.
I was testing with TF GW with original 1.0.12 updated 1.0.32 on untouched remotes and also on module with updated by Dirigera to 1.0.35 (was 1.0.32 before update). All is making one speaker that can being bound to Symfonisk or Sonos speekers. And also one device called shortcut button that can adding single, double and long pressing for shortcut button 1 and 2. Its also make one group but it hidden but then deleting the remote its saying it was deleting group X.
My test device is is having one user data that is not having any data so its using the firmware default and its looks working very good then Diriger have updating it from 1.0.32 to 1.0.35. Also TF GW is not updating the remote also the 1.0.12. I have checking with commander with blank test and the main flash is not as expected and its reporting that user data is blank.
So my conclusion is that your devices is having some strange written in the user data that is making the shortcut ad other devices and i was having the same problem before erasing the user data i was getting 2 extra lights in Dirigera from them. The most strange is that you is also getting it with the untouched one but as i have saying the manufacture can have doing the data setting wrong in the factory posses.
Also possible is that the TF GW is having one hick up and the tested Dirigera 2 but i think its very unlikely that both is having it at the same time.
Can you trying flashing your firmware on one module and writing one empty user data on it and reading it back an look if its only FF
in it and testing paring it with TF GW ?
Symfonisk gen 2 version 1.0.35
ota
file for OTA upgrading and S37 for SWD flashing.
Not tested only done with Dirigera but shall working OK the the signing is OK.
ota_t0x110e_m0x117c_v0x01000035.zip
I have dumped the userdata from an original module, and its content is byte-identical with the one we made. <<update: this is wrong, there are difference from handcrafted userdata >>
S3150FE0020053594D464F4E49534B20736F756E6420CD S3150FE0021072656D6F74652067656E32FFFFFFFFFFD6 S3150FE00220FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE9 S3150FE00230014532313233FFFFFFFFFFFFFFFFFFFFC5
Dump of remote upgrade from 1.0.32 to 1.0.35. IKEA_E2123_1.0.35_firmware.zip
Interesting is this 2 blocks in user data:
0x242-0x243 00 e2
And
0x26a-0x26b 00 00
Both is after the custom name IKEA have putting in and is likely changing the configuration of the device.
Im still confused then my 2 remotes is working OK in TF and DG. I trying flashing your user data an main flash tomorrow and paring and looking how its looking and reporting back.
The name in userdata changed between the 2 versions 1.0.32: SYMFONISK sound remote 2, E2123 1.0.35: SYMFONISK sound remote gen2
Then i must dumping my test module then i was erasing the user data ans it shall being empty. Normal is user data not updated with OTA but its possible but little tricky and i have not seen IKEA doing it before. Normally they is putting in one override name in the OTA firmware and dont need doing extra things.
I have dumped the newest version of the STYRBAR remote firmware: IKEA_E2001_1.0.24.zip for DERIGERA IKEA_E2001_2.4.5.zip for Gateway
TF is looping the update for Styrbar then the OTA file is having one lower number in the meta data (header in the OTA file) then its inside the file and its doing ==
and its not equal and its getting one more update next day after its have flashing the device.
I was erasing my test module that was having the user data empty and flashing your latest bin file for MF and UD and paring it with Dirigera and is getting one device that looks OK. Then paring it with TF and its making one device as one light but with the real name is not one remote (you must have the APP in latest version or is not being shown).
Then erasing the module and writing my empty userdat bin file and doing chip erases and verifying both MF and UD is empty.
Flashing your latest updated file 1.0.35 and paring it with TF and is getting one speaker and one device with with 2 shortcut bottoms. Paring my updated remote and its doing the same.
You see 2 speakers and 2 shortcut buttons the module is running your firmware but with empty user data = its taking the information from the firmware like name and hardware settings and my original updated 1.0.32.
With Dirigera i only getting one speaker but i think the shortcut buttons is being for playlist in Sonos.
Try flashing this file in user data or at 0xFE00000 if cant doing regions on your test module and paring it new with TF GW and look how it working.
PS thanks for the Styrbar with both last versions !!
PPS: Im still confused over that your original dumped user data is not working and its looks like you have writing it by mistake but i think its not possible then the device was debug locked.
TF have posting the last update in the feed:
Super. I will try and see what happes if I join an older version remote to the gateway.
The remote did not appear in the list of device to be updated. But the app said it was updating the devices. It did finish, but the system still thinks the remote is used to control light, not speakers.
My feeling is that is somthing strange with your user data. I was having the same then flashing my first module that was one from one light and was getting one sound remote and 2 lights and flashing one empty user data it was one sound control and 2 shortcut buttons. I was seen your TF is in latest version so its OK (old is not supporting the device) and its making group for the remote but its being hidden in the app and then wrong device type the app is making one light group for it.
I am thinking I will update my last untouch orginal remote in the gateway, and then dump the userdata.
Try but sad that you have not getting on clone working OK then you was sure its working OK and not braking one original one.
Normally shall the user data not being written of OTA files but is possible with MG2X devices.
Also strange that my test with only one module look working OK but i have not testing all the buttons then its need more logic for working but both TF and DG is showing it as my 2 original ones.
I suspect the first update from 1.0.12 to 1.0.32 by hub messed up the userdata, which I then dumped from an original remote. The update to 1.0.35 attempted to fix it, but failed. We will see when I have the userdata from a remote updated from 1.0.12 to 1.0.35 by the gateway.
The userdata for 1.0.35 on gateway is identical to 1.0.32 on hub
1.0.12 to 1.0.35 gateway or 1.0.12 to 1.0.32 hub
S3150FE0020053594D464F4E49534B20736F756E6420CD "SYMFONISK sound " S3150FE0021072656D6F74652067656E32FFFFFFFFFFD6 "remote gen2" S3150FE00220FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE9 S3150FE00230014532313233FFFFFFFFFFFFFFFFFFFFC5 "E2123" S3150FE00240FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC9 S3150FE00250FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFB9 S3150FE00260FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFA9
1.0.12 to 1.0.32 to 1.0.35 hub <<update: this is wrong, it is my handcrafted userdata
S3150FE0020053594D464F4E49534B20736F756E6420CD "SYMFONISK sound " S3150FE0021072656D6F74652032FFFFFFFFFFFFFFFF13 "remote 2" S3150FE00220FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE9 S3150FE00230014532313233FFFFFFFFFFFFFFFFFFFFC5 "E2123" S3150FE00240FFFF00E2FFFFFFFFFFFFFFFFFFFFFFFFE5 S3150FE00250FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFB9 S3150FE00260FFFFFFFFFFFFFFFFFFFF0000FFFFFFFFA7
I think the naming is not very importing only for system like ZHA that is using it for matching quirk for devices but i can that iIKEA is using it 2.
The second is having 00E2
and 0000
in the data that is very likely making things with the firmware is working.
Is one of the 2 version working normal then having pairing it to GW or Hub ?
I was not looking so my test ZHA have updating both .12 and .32 to .35 so i cant looking how it was but the name have not changing in ZHA all 3 is named SYMFONISK sound remote gen2
and it can coming from the user data or the firmware then we is not knowing how IKEA have doing it.
It is good we are logging every step. I have found my mistakes:
So the update never change the userdata. It was me who guess wrong. My mistake only affect the gateway, not the hub.
Fixed firmwares IKEA_E2123_1.0.32_firmware.zip IKEA_E2123_1.0.35_firmware.zip
Me dumping the userdata:
So now you have all old and "new" working well in both system i hope !
I using more or less the same principe with one block with extra long pins that is putting in to middle for fitting the 2.0 mm or is its not working i doing one fast soldering on the module if its not easy holding it in place on some devices.
Styrbar dumped:
Looks your next device is in the pipe then its being leaked and its on the way. https://www.reddit.com/r/tradfri/comments/13f29wy/app_mentions_new_rodret_dimmer_any_details/
Also in Austria IKEA have start updating all descriptions of all TF devices with connecting dimmer switch with RODRET instead or the OnOff dimmer switch.
How is your updated hardware of Symfonisk II working ?? Is all OK after getting the updated hardware and the firmware fixed ??
I saw it the 25. of febuary here: https://fccid.io/FHO-E2201/Letter/Model-Declaration-Letter-6321956.iframe
I think it will replace the ON/OFF, curtain and shortcut button. So IKEA will use the new ZigBee module there also.
The Symfonisk gen 2 to FUGA has one issue. The shortcut buttons can only send long press. Not short of double press. This might be fixed by changing the resistor and capacitor values.
Then using one new module without any caps and resistors is nearly impossible getting button events being triggered by using one pull down resistor then its need one pull up on PA03 for scanning the button input ports. The key function is the PA03 that is working as one trigger for scanning the other inputs for changes. If the R and C components is not working OK you is not getting any triggering then pressing the buttons then the timing of PA03 + the button input is not in sync / wrong time / DC level. Also check the DC levels on the button inputs and PA03 then not pressed and pressed and comparing with the original PCB mounted module if you is getting the same readings.
6.99 € is better then the first gen buttons.
Now we must waiting @CableCatDK is baying one and using the hammer on it so we is knowing how its look inside and the PCB layout.
Sorry its no Silabs module inside they have making on compact PCB with integrated antenna and on tiny shielded very like EEFR32MG21 chip but its looks nice and cas they was not doing the same with Symfonisk 2 and Styrbar then have making them more compact. Its also looks they is having one stepup converter so can using rechargeable batteries then it shall being tricky without it getting the radio and CPUs working stable.
I is missing test pas for the chip rest that can being good to have then recover chips that have getting problems but perhaps its hidden someplace.
Was trying connecting to the debug with my Silabs WSDK but it was not liking it. Was looking on the power and with one 1.5V battery the pads is having 2.22V so the next try was without the plus and only GND and the debug lines but still mot like talking to my. With the old IKEA module its looks Segger have make changes and its needs the hardware rest for getting the chip in debug mode, The problem here is the we dont have the reset exposed. In GSDK its possible using some of the debug lines for other things then booting the app and then one hardware reset is needed for hocking the chip in early stage of booting before its disabling the debug interface. I can IKEA have using that trick.
If some one have one device and one SWD debugger pleas try see if can getting contact with the chip then its more then likely on EFR32MG21 without hardware secure storage as the normal MG21 module is using but i can its have other ports that the module but its depends of the chip version used. I have not being so brutal as our Danish friend so no hammer for getting the chip "free" yet.
@MattWestb :
You can access RESETn at the following location, outside the shield can:
I tried first with a converted ST-Link to J-Link without much success.
I then used a Simplicity Link Debugger and was able to read Info etc.
Flashing the baremetal blink exampled worked without an issue.
Sound great and thanks @jlunz !! So IKEA have labeling it GND (i was reading on my PCB but on your photo is C10) for making all creative persons not testing it !!!! So with WSTK it was working then you also connected the chip reset ? The good thing is looks IKEA have not debut logging your device so it shall being possible using it for future device "conversion" . Can you reading / dumping the main flash and the user data then we can needing it for the OpenClose and shortcut buttons and perhaps is they is doing one updated valve remote.
Also most J-Link clones is not working with MG2X chips then dont have the security implanted in the debugger and if converting it with Segger its being locked to only flashing the OME (ST) chips. WSTK is having some magic implanted so its possible recovering MG1X chips (i gave hard soft braking 3 modules but was able recovering them with the WSTK by stalling the processor with the reset).
I shall making one test dumping the flash in the weekend and reporting back.
Do you also have "found " the pin / pad function so we can see if its possible flashing it on the normal MG21 module ?
One more thanks for the great information !!!
I was not completely sure if I had unlocked debug access / erased flash with my ST-Link before, so I wired up a new remote. It seems that the device is locked, I am getting the following output. Anything I should / can try before a erase?
commander device --device EFR32MG21A010F1024IM32 info
JLinkError: Could not find core in Coresight setup
WARNING: Could not connect to target device
ERROR: Debug access is locked. Could not connect to device
DONE
Servus J.
OK the chip was debug locked ;-((
Can you dumping the user data flash part ? Its holding the hard and software configuration IKEA is using for the device and with it we can using one unlocked chip and flashing one bootloader from STYRBAR and flashing the extracted OTA file and the device shall working OK (was working with Symfonisk G2).
I have not have time looking on my test device but i have 2 in production and looks working great but one LIDL / tuya power strip was playing nasty games and was destroying my production network by have power problems and one IKEA outlet and one GU10 CWS3 was repowering oft and was making device accouterments that is being badly handled by all silabs chips and must being repowered for working OK after that (shall being fixed in later Zigbee stacks).
Thanks for sharing your findings and good hacking for you.
Edit: Debug unlock is erasing the main flash and the RAM but not the user data then we have testing and looks working OK so we cant dumping the main flash but as long IKEA have not doing more trikes we can using one standard bootloader and for getting it working OK we hope.
Ok, just to be sure: I unlock:
commander device lock --debug disable
and then try to read userdata:
commander readmem --region @userdata --outfile dumpuser.hex
I think you can doing the unlock from GUI but i have not trying it and shall doing the same thing as the CLI.
I was not getting the region working but other users was having working OK so i was using memory addresses and its working the same way and shall being OK.
It can being that you need adding the standard -device EFR32MG21A010F1024IM32
so commander is knowing the chip layout or its complaining.
Out file is HEX good i normally making more formats if some its not being OK and BIN is easy reading and editing but no check for errors but all is working and can being converted with commander if the in file is OK.
Here we go: dumpuser(bin,hex,s37).zip
It has the following in:
00000000: ffff ffff ffff ffff ffff ffff ffff ffff ................ ... 000001f0: ffff ffff ffff ffff ffff ffff ffff ffff ................ 00000200: 524f 4452 4554 2044 696d 6d65 72ff ffff RODRET Dimmer... 00000210: ffff ffff ffff ffff ffff ffff ffff ffff ................ 00000220: ffff ffff ffff ffff ffff ffff ffff ffff ................ 00000230: 0145 3232 3031 ffff ffff ffff ffff ffff .E2201.......... 00000240: ffff 00e2 ffff ffff ffff ffff ffff ffff ................ 00000250: ffff ffff ffff ffff ffff ffff ffff ffff ................ 00000260: ffff ffff ffff ffff ffff 0000 ffff ffff ................ 00000270: ffff ffff ffff ffff ffff ffff ffff ffff ................ ... 000003f0: ffff ffff ffff ffff ffff ffff ffff ffff ................
Thanks its looks very good perhaps i shall flashing it one one MG21 module but i dont knowing the pinout of the paring and the up and down buttons so not so easy testing is its working more then the name is OK red.
The interesting is the 0X24x and 0X26x that is doing the hard and software settings of the device if its being one OnOff, OpenCloce or one Shortcut button.
Thanks its looks very good perhaps i shall flashing it one one MG21 module but i dont knowing the pinout of the paring and the up and down buttons so not so easy testing is its working more then the name is OK red.
You're welcome! Pinout on the E2201 is: Red LED: LED1 / PD00 Button "0": S1 / PA04 Button "∞": S2 / PA06 Button "1": S3 / PA03
Thank one more time i shall look if the information and doing some digging and test. The MGM210L is having all pins / pads but the PA06 is not led to one pad so its shall working for all functions but its not possible pairing the module with that firmware but can perhaps being done with one other like Styrbar and then flashing only the OTA file so the NVM blocks is not erased but its little work testing if its working OK.
By the way then you have getting the blink working, then is you releasing your multi functions firmware for the device with okta button press and so on ???? ;-)
How do you pull a button? On STYRBAR it is short to GND. But on SYMFONISK it is short to PA03.
S2 Pairing is shutting to GND but the other 2 is not GND but can being VSS after the voltage regulator then its not + from the battery. Must looking more.
Edit: S3 is using the same 2 liens as LED1 and no GND is being used for it so must using shifting polarity or shutting the LED for the button press. Non of the 2 liens is being used for S1 that must using other logic. Also from the VDD test pas is not contact to the swishes.
Edit 2 Updating my observations and test: All swishes is shutting to GND also the LED is having GND on the negative side so its no magic here only that the chip is using 3 pins for waking up from sleep.
I have unpacking the OTA file from TF OTA-feed and converting it to GBL, S37 and BIN if some one like trying recreating one working device by first flashing one working boot loader and then the "APP". E2201-OTA.zip Try first with one STYRBAR bootloader then its one of the latest not locked we have dumped that was working OK with Symfonisk 2.
I was testing connecting the PCB with my WSDK and also shouldering the reset cable and i was miss interpreting the commander then its writing "could not connect to target device" but after little trixing i cant getting the MAC and the secure elements stratus.
That is true then the MCU is not online then the chip is debug locked and we can only talking with the security processor and getting the status from the secure elements but with that we is getting the status we like / need.
I also have long long cables so some time i must putting the SWD speed down from 8000 for getting it working but must testing if reading the memory map and flashing is working for knowing its OK speed.
Also its looks like the reset is not needed for getting this information but have not testing doing on unlock if its working OK without it and also getting it flashing working OK.
Then i have time i shall trying flashing the user data and the patched main flash and testing if i can getting it to work on one MG21 chip without IKEAs locked chip.
@MattWestb I dumped 47 x ICC-A-1 from different devices. I might be useful. IKEA_ICC-1_ICC-A-1_dump.zip
I have not time but i thinking doing one coordinator as i have doing with the first and second gen module of the Rodret remote it shall not being any large problem only finding the right pins on the chop and soldering cables. I can that the RP part is limited RF power but is the same with the modules the is not using the max for getting stability and one symmetric RF link.
Have you thinking doing one switch by cutting of the PCB and connecting your switches instead of the Silabs module ?
Have you thinking doing one switch by cutting of the PCB and connecting your switches instead of the Silabs module ?
I have not rally looked into the Rodret remote. Its large size only fits 1M5 FUGA modules (68mm high). For that size you really want at least 6 buttons, not only 2. So maybe one could flash to SYMFONISK firmware on it. Then make a daughterboard with 6-8 buttons. The result would be a 1M5 FUGA switch which uses 1xAAA batteri, but requires space behind it.
My current SYMFONISK to FUGA conversion uses 2xCR2032, and can be mounted directly on the wall.
Alkaline AAA: 860–1,200 mAh CR2032: 220 mAh
Rodret PCB is having one buck converter (FCC papers is saying its 2 different types is being used) but i think its not working with CRXXXX cells and putting in one AAA is taking too much space so no go. The module is using one different MG21 chip that is using different ports so can being its not working but i have not testing it serious only fast flashing it and its not running on the module.
hi
this project on thingiverse https://www.thingiverse.com/thing:3655354 has been much fun to me
it was easy to remove a zigbee module from their light bulbs and then reprogramm it to work as a 5 button remote
but now ikea is slowly replacing their zigbee modules with a new one that for the bulbs concern are far more power hungry and why should ikea bother as they are intended to be always on mains power
and their new 5 button remote do not have a module at all but is one complete pcb and to top it off they now use 2 AAA batteries
that makes it impossible to install it in the danish LK Fuga design, it will simply be to big to sit flush with the other switches
anyone that have started to look in to if the new modules can be reprogrammed to work as a remote and be energy efficient so that it can run on coin cells?
i emagine that the firmware needs to be taken from the new 5 botton remote and changed so that its as efficent as possible
of course the chip on the new module an the new 5 botton remote needs to be the same
and the pcb in the new remote is way to be to be but in a LK switch, from what i have seen online its 2 cm to big in each direction