unleashed-firmware
unleashed-firmware copied to clipboard
DarkFlippers
CAME 12bit not working
Describe the bug.
When reading a signal from a remote the decode works good but when send that signal it is not working well. With previous version 020 it read Key 0x00000296 and when send this signal to my gate it works good. After update to flipper version 023 the previous saved signal stop working. If I make another read from the same remote it read Key 0x00000296 as before, but sending it to the gate will not work. RAW reading and sending of the same signal is working fine. I suppose is something related to the encoding of the signal before sending.
Reproduction
- read and save a 433.88 Mhz signal from a CAME 12 bit remote
- save it on flipper
- send the signal to the gate
- Gate is not opening.
Target
No response
Logs
No response
Anything else?
No response
Provide more details and RAW recordings of original remote, also your frequency looks not correct, change it to 433.92 and try again
I have the same problem.
Previously working file
Filetype: Flipper SubGhz Key File Version: 1 Frequency: 433920000 Preset: FuriHalSubGhzPresetOok270Async Protocol: CAME Bit: 12 Key: 00 00 00 00 00 00 0B FD Repeat: 200
Playing that file back now does nothing.
Reading the same signal from the remote now, the flipper is not capturing the key correctly and is detecting a different protocol.
Read for same signal
Filetype: Flipper SubGhz Key File Version: 1 Frequency: 433920000 Preset: FuriHalSubGhzPresetOok270Async Protocol: Holtek_HT12X Bit: 12 Key: 00 00 00 00 00 00 0F FF TE: 255
Playing back the file does nothing.
Editing the key in the file works. Working file
Filetype: Flipper SubGhz Key File Version: 1 Frequency: 433920000 Preset: FuriHalSubGhzPresetOok270Async Protocol: Holtek_HT12X Bit: 12 Key: 00 00 00 00 00 00 0B FD TE: 255
It looks like Flipper is detecting the incorrect protocol which is stopping it reading the key correctly.
I have the same problem.
Previously working file
Filetype: Flipper SubGhz Key File Version: 1 Frequency: 433920000 Preset: FuriHalSubGhzPresetOok270Async Protocol: CAME Bit: 12 Key: 00 00 00 00 00 00 0B FD Repeat: 200Playing that file back now does nothing.
Reading the same signal from the remote now, the flipper is not capturing the key correctly and is detecting a different protocol.
Read for same signal
Filetype: Flipper SubGhz Key File Version: 1 Frequency: 433920000 Preset: FuriHalSubGhzPresetOok270Async Protocol: Holtek_HT12X Bit: 12 Key: 00 00 00 00 00 00 0F FF TE: 255Playing back the file does nothing. Editing the key in the file works. Working file
Filetype: Flipper SubGhz Key File Version: 1 Frequency: 433920000 Preset: FuriHalSubGhzPresetOok270Async Protocol: Holtek_HT12X Bit: 12 Key: 00 00 00 00 00 00 0B FD TE: 255It looks like Flipper is detecting the incorrect protocol which is stopping it reading the key correctly.
Provide RAW recordings of your original remote!
Here are three recordings of the same signal. Playing the raw signal back works to trigger the light on/off. Going More > Decode > Send does not trigger the light and shows the same key as above (x0 00) RAW_20230116-201853.sub.txt RAW_20230116-201611.sub.txt RAW_20230116-201910.sub.txt
Release 30 still have the same behaviour with came protocol. I do believe that everything started here https://github.com/flipperdevices/flipperzero-firmware/commit/21a3656c7d521f386b3effce2b330ac064bc371e
Release 30 still have the same behaviour with came protocol. I do believe that everything started here flipperdevices/flipperzero-firmware@21a3656
I'm still waiting for raw recordings of your remote, also i want to see a photo of the remote, looks like your remote is not original CAME previous guy who sent recordings tells about "light", CAME is protocol used by gates, barriers, not lights so looks like you may have similar situation
Here the raw data, that is currently working and can open the gate. https://dev.flpr.app/sf#path=subghz/Gar_mio.sub&key=bkREMVTAlYO-bzqJUTrSdw%3D%3D&id=9BnaV9
That one down here is the decoded signal that used to work with previous versions until 23 https://dev.flpr.app/sf#path=subghz/Random_sidorovich.sub&key=VqmuNTp4ZZbIJHC41NwcSA%3D%3D&id=R6xly7
The fob is currently open a gate but it is not an original came fob
IMG_7703 - Copy IMG_7708 - Copy IMG_7706 - Copy IMG_7704 - Copy
For the remote that is the light/fan remote - see photos attached.
If I'm understanding the message above with the commit link, the original behaviour was a bug (that detected the wrong protocol) which has now been fixed.
If that's the case how was it still able to work pre-fix but not post-fix?
https://user-images.githubusercontent.com/121310844/219873425-dacc85dc-b0a1-4721-8d27-1b80688607f3.mp4
I have no idea what is wrong. It detects the right protocol and I suppose also the right code, because 296 is the same code it used to detect with version 20. But when I send that signal it doesn't work. It used to work well with version 20 and stop working with version 23
Same problem for me. I have CAME and NICE 433 saved remote (brute forced or cloned) which worked well, but since many fw version, when emulating, nothing happens.
Same problem for me. I have CAME and NICE 433 saved remote (brute forced or cloned) which worked well, but since many fw version, when emulating, nothing happens.
Nice wasn't changed in any way and your issue is not related to this thread, also you provided 0 details of your case
Thanks for the fix dani84bs, works ok now on our gate faac 868 12 dip. If its not hijacking , also happened to have problems as well on faac slh 868 64bit same as the CAME one. Well done mate
Thanks for the fix dani84bs, works ok now on our gate faac 868 12 dip. If its not hijacking , also happened to have problems as well on faac slh 868 64bit same as the CAME one. Well done mate
How FAAC is related to CAME protocol?
Please verify original CAME 12 bit remote emulation with original CAME system I made fixes in dev branch, please tell if it works for you
Im not Accepting any issues about non CAME systems in this thread, please don't post results about FAAC or other not related protocols, but if it fixed their support feel free to post results just for info