xoseperez / espurna

Home automation firmware for ESP8266-based devices
http://tinkerman.cat
GNU General Public License v3.0
2.98k stars 637 forks source link

Support of additional comands from Portisch/RF-Bridge-EFM8BB1 #668

Open Portisch opened 6 years ago

Portisch commented 6 years ago

Hi,

the PT226x (original supported protocol) is almost fixed.

May it is time to implement the new comands for the alternative EFM8 firmware: https://github.com/Portisch/RF-Bridge-EFM8BB1

0xFF Check if the EFM8 chip is running the alternative firmware.

0xA6 Start sniffing of defined protocols in RF_Protocols.h.

0xA7 Stop sniffing and restart "standard" sniffing for PT226x devices.

0xA8 New transmit by protocol identifier 0x01 - 0x7E.

0xA8 New transmit by protocol identifier 0x7F. RF messages can be build any way you like.

0xA9 New learning of predefined protocols defined in RF_Protocols.h.

0xB1 Start bucket sniffing

0xC0 Do a beep

zerog2k commented 6 years ago

@Portisch I flashed your efm8 fw and using latest espurna. Noticing that:

  1. wont start coming in til I run "learn" command at least once... I assume this is putting the efm8 fw into some mode (not sure which one?), and
  2. the rfin data is 9 bytes, and first 6 seem random, while last 3 are always same for given device/button/etc. As a 24-bit address, I think this is expected? These are some Digoo HOSA modules, which I use HS2303 (I think PT2262 compatible chipset ?)

example:

{"rfin":"366A014004C401C8E8","time":"2018-05-31 15:48:04","mac":"60:01:94:8E:7D:F9","host":"ESPURNA_8E7DF9","ip":"192.168.1.16","id":10375}
{"rfin":"366A017204A601C8E8","time":"2018-05-31 15:48:10","mac":"60:01:94:8E:7D:F9","host":"ESPURNA_8E7DF9","ip":"192.168.1.16","id":10377}

I'm wondering if this is because this needs to be supported in espurna ? @xoseperez is there a way we can tx and rx raw commands to efm8 I'm looking at wiki and #386, and it seems like maybe we can use /rfraw/set ?

xoseperez commented 6 years ago

The first 6 are not random, only slightly different. These are timings (sync, on, off) and could be a dim different for each capture.

@Portisch has extended the original protocol with more codes for new actions. This way it is still compatible with other firmwares that might only use the original commands.