Troubles sending commands via serial to check firmware install about rf-bridge-efm8bb1 HOT 22 CLOSED

@swampdogmash The eaysiest way to check if the firmware is loaded to the EFM is as follows.

In ESPURNA file general.h line 842:
#define RF_RAW_SUPPORT 0 // RF raw codes require a specific firmware for the EFM8BB1
Change to
#define RF_RAW_SUPPORT 1 // RF raw codes require a specific firmware for the EFM8BB1

In ESPURNA file rfbridge.ino line 311:
//DEBUG_MSG_P(PSTR("[RFBRIDGE] Received 0x%02X\n"), c);
Change to
DEBUG_MSG_P(PSTR("[RFBRIDGE] Received 0x%02X\n"), c);

Now compile ESPURNA and load it to the bridge.

In ESPURNA web configuration configure MQTT in a way it connects to your MQTT broker and in the "ADMIN" tab enable telnet.
Reboot ESPURNA and connect to the bridge with telnet. If you now send:
(Keep watching the telnet window all data returning from the EFM chip will roll over your screen)
AAC001F455 to MQTT topic {bridge host name}/rfraw/set You hear a short beep
AAFF55 to MQTT topic topic {bridge host name}/rfraw/set You see the firmware version in the telnet window.

from rf-bridge-efm8bb1.

Thanks Albert. I'll take a look at this tonight :)

from rf-bridge-efm8bb1.

I've worked my way through those instructions - the beep seems to work... but issuing AAFF55 seems to cause a reboot of Espurna after telnet shows that command was sent and issued to EFM. Sorry if I am being a bit stupid here - not sure what to do next.

Actually scratch part of that - the reboot seems to be something else . Telnet disconnects but I cannot figure out why yet. Could be that for some reason I couldn't select "v1.4 PRebuilt" as my build options which i need to figure out why too). And I get no response from AAFF55 or AAA655. I can see the commands appearing in telnet as "sent to EFM" but no return response. I DO get a beep when i send AAC001F455 though.

Yet another edit:

Whilst Espurna was stable i managed to issue a AAB155 and see that some codes were received - now I just don't know what to do to "learn" them or see the data on rfraw (can't see anything urrently so do I need further steps?)

from rf-bridge-efm8bb1.

So I managed to capture this and I think decode it myself but what now? IS ther ean easier way to capture the code?

Couple of thing to note - implicit CR/LF needs to be turned on in telnet when listening for incoming codes after having sent an AAB155 or it's not too easy to see the data.

[512988] [RFBRIDGE] Received 0xAA uart sync
[512989] [RFBRIDGE] Received 0xB1 bucket sniffing
[512989] [RFBRIDGE] Received 0x04 bucket count
[512990] [RFBRIDGE] Received 0x04 0439
[512990] [RFBRIDGE] Received 0x39 = 1081 us bucket1 length
[512990] [RFBRIDGE] Received 0x01 01C5
[512990] [RFBRIDGE] Received 0xC5 = 453 us Bucket 2 length
[512990] [RFBRIDGE] Received 0x0B 0BAE
[512991] [RFBRIDGE] Received 0xAE = 2990 us Bucket 3 length
[512991] [RFBRIDGE] Received 0x1C 1C3E
[512991] [RFBRIDGE] Received 0x3E = 30ms Bucket 4 length (sync)
[512991] [RFBRIDGE] Received 0x01 Data
[512991] [RFBRIDGE] Received 0x10 |
[512992] [RFBRIDGE] Received 0x10 |
[512992] [RFBRIDGE] Received 0x10 |
[512992] [RFBRIDGE] Received 0x10 |
[512992] [RFBRIDGE] Received 0x01 |
[512993] [RFBRIDGE] Received 0x01 |
[512993] [RFBRIDGE] Received 0x01 |
[512993] [RFBRIDGE] Received 0x10 |
[512994] [RFBRIDGE] Received 0x10 |
[512994] [RFBRIDGE] Received 0x01 |
[512994] [RFBRIDGE] Received 0x01 |
[512994] [RFBRIDGE] Received 0x10 |
[512994] [RFBRIDGE] Received 0x10 |
[512995] [RFBRIDGE] Received 0x01 |
[512995] [RFBRIDGE] Received 0x01 |
[512995] [RFBRIDGE] Received 0x01 |
[512995] [RFBRIDGE] Received 0x10 |
[512995] [RFBRIDGE] Received 0x01 |
[512996] [RFBRIDGE] Received 0x01 |
[113888] [RFBRIDGE] Received 0x10 |
[113888] [RFBRIDGE] Received 0x10 |
[113889] [RFBRIDGE] Received 0x10 |
[113889] [RFBRIDGE] Received 0x10 |
[113889] [RFBRIDGE] Received 0x20 |
[113889] [RFBRIDGE] Received 0x55 uart sync end

from rf-bridge-efm8bb1.

AA B1 0439 01C5 0BAE 1C3E 01101010100101011010010110100101011001011010101020 55

When the signal can be sniffed it can be defined in RF_Protocols.h. But I have to think before about a structure for bucket codes...

from rf-bridge-efm8bb1.

I also managed to get feedback from every command including collecting the bucket code as above.

One thing I did find useful though was rather than sending by mqtt I put the command I wanted to send into code 0 on the RF page in espurna1 (for both the on and off command) and thus could test both Espurna sending to the efm chip and the erm chip response via telnet by switching switch 0 on and off. I could see the responses in telent window

Very clever firmware and I now understand it better but need to get to grips with how to send a bucket code.

I did notice that for the b0 command you mention 2 elements that should be added to the he's codes sent but they don't actually appear in the example string. Sync-low and bit high seem to be listed but not in the example for some reason and I didn't know where to find them

from rf-bridge-efm8bb1.

I did some calculation on your received buckets.
It looks like not bucket because the data include only 2 different bucket timings.
Also it only have 01 or 10 in the data.
This shows 01: Bit 1, 10: Bit 0.
This is because bucket 0 is 1081µs and bucket 1 is 453µs.

Can you tell me more about your RF remote. What brand, what for,....
I will need some data/information to define a protocol in the firmware.

This will be the decoded data:

AA: uart sync
A6: sniffing command
04: len
06: protocol identifier - unkown, needs to defined by @swampdogmash
87 33 B0: 24 bit data
55: uart sync end

So this shows bucket sniffing 0xB1 can be used to define and implement new protocols.

from rf-bridge-efm8bb1.

I've been trying to find that out myself actually and been struggling so I wondered if this firmware would help me understand what it is :p

It was something bought at Aldi I believe - it is their 4 RF socket system

https://www.youtube.com/watch?v=aVuKzI7mBsU

I've had the remote apart and can't find any detail on the chips in there and no sensible codes. I've had the sockets aprat to no avail too.

from rf-bridge-efm8bb1.

The protocol got added in the firmware: df3763c
Now it should be possible to use command 0xA6 (sniffing), 0xA8 (transmit) and 0xA9 (learning) for your remote.

from rf-bridge-efm8bb1.

Thanks - does the protocol have a specific name? (I just saw you have added it under the generic product name - ty). Would be good to see what it is. I wasn't expecting you to add it so quickly, so thanks - but I think it best if i capture the same code more than once, and some other codes to validate the protocol? What do you think?

from rf-bridge-efm8bb1.

Your protocol do have this number:
#define ALDI_RCWS_IDENTIFIER 0x06

I also didn't know that it is that easy to add a new protocol... ;)

And yes, please test it with command 0xA6 if your remote can be decoded.

You should receive something like this:
AA A6 04 06 xx xx xx 55

Than you can try to transmit like this:
AA A8 04 06 xx xx xx 55

from rf-bridge-efm8bb1.

Cool, i've loaded the latest firmware that you uploaded earlier and now when i do an A6 I get this...

[419830] [RFBRIDGE] Sending RAW MESSAGE 'AAA655'
[419852] [RFBRIDGE] Received 0xAA
[419853] [RFBRIDGE] Received 0xA0
[419853] [RFBRIDGE] Received 0x55
[419853] [RFBRIDGE] Action 0xA0

Press button channel 1 "on" on the remote and get this:
[427695] [RFBRIDGE] Received 0xAA
[427696] [RFBRIDGE] Received 0xA6
[427696] [RFBRIDGE] Received 0x04
[427696] [RFBRIDGE] Received 0x06
[427696] [RFBRIDGE] Received 0x8C
[427697] [RFBRIDGE] Received 0x60
[427697] [RFBRIDGE] Received 0x40
[427697] [RFBRIDGE] Received 0x55

522624] [MQTT] Received Espurna1/rfraw/set => AAA655
[522630] [RFBRIDGE] Sending RAW MESSAGE 'AAA655'
[522653] [RFBRIDGE] Received 0xAA
[522654] [RFBRIDGE] Received 0xA0
[522654] [RFBRIDGE] Received 0x55

PRess same button again
[526462] [RFBRIDGE] Received 0xAA
[526463] [RFBRIDGE] Received 0xA6
[526464] [RFBRIDGE] Received 0x04
[526464] [RFBRIDGE] Received 0x06
[526464] [RFBRIDGE] Received 0x8C
[526464] [RFBRIDGE] Received 0x60
[526464] [RFBRIDGE] Received 0x40
[526464] [RFBRIDGE] Received 0x55

Which is consistently the same.
Using another button gives slightly different results. For instance, Channel 1 "off" gives randomly:

AA A6 04 06 821520 55
AA A6 04 06 868210 55
AA A6 04 06 821520 55
AA A6 04 06 852990 55

Sending back the command with A8 even for the "ON" signal doesn't seem to trigger the device to turn on.

from rf-bridge-efm8bb1.

Back to capturing by bucket again and things seemed to swap betwee 4 to 5 buckets and then stay at 5. Not sure if this is just a timing thing or what. THe captures below are for just the on button repeated once every 2 seconds or so.

AA B1 04 0437 01C7 0BB8 1C34 011010100101101010010110101010101001101010101010 23 55
AA B1 04 0431 01CD 0BAE 1C2A 011010100110010101010101100110101001010110101010 23 55
AA B1 05 0441 01DA 01AB 0BA4 1C5C 011010101001010110100101101001010110010110101010 34 55
AA B1 05 0443 01C3 01AA 0BA4 1C48 011010101010010101100101100101011010010110101010 34 55
AA B1 05 044E 025B 01AC 0BA4 1C3E 011010100101101010010110101010101001101010101010 34 55
AA B1 05 0447 0208 01AD 0B90 1C52 011010100110010101010101100110101001010110101010 34 55
AA B1 05 0443 01C1 01A3 0BAE 1C52 011010101001010110100101101001010110010110101010 34 55
AA B1 05 0443 0258 01AD 0BA4 1C66 011010101010010101100101100101012010010110201010 34 55

from rf-bridge-efm8bb1.

I did some research for this remote:

2957 7194 343 1092 407 1143 373 1133 390 1103 912 609 913 593 912 594 940 629 389 1113 923 598 919 590 969 553 977 549 918 595 405 1116 1024 505 391 1113 921 591 1006 547 962 542 395 1119 394 1159 431 1094 346

As you can see the timing is really bad on this remote. Bit 5 have 912 high and 609 low time.
This is a duty cycle of ~60%. So I think the only way to decode this remote is like if high time is lower than 700us it's bit 0, if higher than 800us it's bit 1.
But this is another type of decoding...

I will make tomorrow a new branch for testing where the duty cycle tolerance can be adjusted.

from rf-bridge-efm8bb1.

It's clearly a crazy remote.... do you have any links to any research for completeness of understanding?

from rf-bridge-efm8bb1.

I pushed a new branch: 7d37e05
There you can define a duty cycle tolerance for each protocol. Default is 8% - for yours we try first 15%.
Please test if the sniffing by command 0xA6 is now more stable.

Here I found some information about the wall plugs:
https://forum.pilight.org/showthread.php?tid=1496&page=11

from rf-bridge-efm8bb1.

Good day Portisch....

Have loaded the latest firmware you published and these are the results for Channel 1 "On" and Channel 1 "Off". I am not sure the change you have made has had the effect that was desired - IS there a way to check the "specific" version number of the firmware loaded just in case it didn't flash a new one?

I'm pretty sure it did flash correctly - 2 reasons - 1 - saw the HTTP server for "prog" the programmer scrolling the Hex blocks to the arduino uno and 2 - the Bridge beeped after flashing complete.

Repeatedly sending codes using A8 'will' work but VERY VERY occasionally, so I suspect a timing issue still.

Channel 1 "On"
[395801] [RFBRIDGE] Received 0xAA
[395802] [RFBRIDGE] Received 0xA6
[395802] [RFBRIDGE] Received 0x04
[395803] [RFBRIDGE] Received 0x06
[395803] [RFBRIDGE] Received 0x8B
[395803] [RFBRIDGE] Received 0xF4
[395803] [RFBRIDGE] Received 0x70
[395803] [RFBRIDGE] Received 0x55

[397281] [RFBRIDGE] Received 0xAA
[397282] [RFBRIDGE] Received 0xA6
[397283] [RFBRIDGE] Received 0x04
[397283] [RFBRIDGE] Received 0x06
[397283] [RFBRIDGE] Received 0x87
[397283] [RFBRIDGE] Received 0x33
[397283] [RFBRIDGE] Received 0xB0
[397283] [RFBRIDGE] Received 0x55

[398517] [RFBRIDGE] Received 0xAA
[398518] [RFBRIDGE] Received 0xA6
[398518] [RFBRIDGE] Received 0x04
[398518] [RFBRIDGE] Received 0x06
[398519] [RFBRIDGE] Received 0x83
[398519] [RFBRIDGE] Received 0xB7
[398519] [RFBRIDGE] Received 0x30
[398519] [RFBRIDGE] Received 0x55

[399711] [RFBRIDGE] Received 0xAA
[399712] [RFBRIDGE] Received 0xA6
[399712] [RFBRIDGE] Received 0x04
[399713] [RFBRIDGE] Received 0x06
[399713] [RFBRIDGE] Received 0x8C
[399713] [RFBRIDGE] Received 0x60
[399713] [RFBRIDGE] Received 0x40
[399713] [RFBRIDGE] Received 0x55

And Channel 1 "Off"
[522858] [RFBRIDGE] Received 0xAA
[522859] [RFBRIDGE] Received 0xA6
[522860] [RFBRIDGE] Received 0x04
[522860] [RFBRIDGE] Received 0x06
[522860] [RFBRIDGE] Received 0x85
[522860] [RFBRIDGE] Received 0x29
[522860] [RFBRIDGE] Received 0x90
[522860] [RFBRIDGE] Received 0x55

[524103] [RFBRIDGE] Received 0xAA
[524104] [RFBRIDGE] Received 0xA6
[524105] [RFBRIDGE] Received 0x04
[524105] [RFBRIDGE] Received 0x06
[524105] [RFBRIDGE] Received 0x8D
[524105] [RFBRIDGE] Received 0xE8
[524105] [RFBRIDGE] Received 0xA0
[524105] [RFBRIDGE] Received 0x55

[525267] [RFBRIDGE] Received 0xAA
[525268] [RFBRIDGE] Received 0xA6
[525268] [RFBRIDGE] Received 0x04
[525269] [RFBRIDGE] Received 0x06
[525269] [RFBRIDGE] Received 0x82
[525269] [RFBRIDGE] Received 0x15
[525269] [RFBRIDGE] Received 0x20
[525269] [RFBRIDGE] Received 0x55

[526748] [RFBRIDGE] Received 0xAA
[526749] [RFBRIDGE] Received 0xA6
[526749] [RFBRIDGE] Received 0x04
[526749] [RFBRIDGE] Received 0x06
[526749] [RFBRIDGE] Received 0x86
[526750] [RFBRIDGE] Received 0x82
[526750] [RFBRIDGE] Received 0x10
[526750] [RFBRIDGE] Received 0x55

from rf-bridge-efm8bb1.

I added another commit to the Duty_Cycle branch: 9fce9e7
This will show now version 0x01 - just for control...

But I think I will do some other modifications:
When for a protocol defined in the RF_Protocols.h the duty cycles for high and low bit are 0 only a high/lower time compare will happen to detect the bits. I will do this tomorrow.

from rf-bridge-efm8bb1.

Thanks - I'm not at work for the next week or so at the moment so I can do a fair bit of testing over the next 2 weeks if that helps. I've loaded the latest firmware and confirmed that the response to AAFF55 is 1. At least we know where we are with regard to the versioning in this particular case :)

I'm still getting eartic results from sniffing using A6 - not sure what to think. Replaying any of the captured codes using A8 doesn't seem to do anything. Have copied som example captures again below:

Channel 1 "ON"
[741024] [RFBRIDGE] Received 0xAA
[741025] [RFBRIDGE] Received 0xA6
[741025] [RFBRIDGE] Received 0x04
[741025] [RFBRIDGE] Received 0x06
[741026] [RFBRIDGE] Received 0x8B
[741027] [RFBRIDGE] Received 0xF4
[741027] [RFBRIDGE] Received 0x70
[741027] [RFBRIDGE] Received 0x55

[742282] [RFBRIDGE] Received 0xAA
[742283] [RFBRIDGE] Received 0xA6
[742283] [RFBRIDGE] Received 0x04
[742283] [RFBRIDGE] Received 0x06
[742283] [RFBRIDGE] Received 0x87
[742284] [RFBRIDGE] Received 0x33
[742284] [RFBRIDGE] Received 0xB0
[742284] [RFBRIDGE] Received 0x55

[744606] [RFBRIDGE] Received 0xAA
[744607] [RFBRIDGE] Received 0xA6
[744607] [RFBRIDGE] Received 0x04
[744607] [RFBRIDGE] Received 0x06
[744608] [RFBRIDGE] Received 0x83
[744608] [RFBRIDGE] Received 0xB7
[744608] [RFBRIDGE] Received 0x30
[744608] [RFBRIDGE] Received 0x55

[745849] [RFBRIDGE] Received 0xAA
[745850] [RFBRIDGE] Received 0xA6
[745850] [RFBRIDGE] Received 0x04
[745851] [RFBRIDGE] Received 0x06
[745851] [RFBRIDGE] Received 0x8C
[745851] [RFBRIDGE] Received 0x60
[745851] [RFBRIDGE] Received 0x40
[745851] [RFBRIDGE] Received 0x55

[749726] [RFBRIDGE] Received 0xAA
[749728] [RFBRIDGE] Received 0xA6
[749728] [RFBRIDGE] Received 0x04
[749728] [RFBRIDGE] Received 0x06
[749728] [RFBRIDGE] Received 0x8B
[749728] [RFBRIDGE] Received 0xF4
[749728] [RFBRIDGE] Received 0x70
[749729] [RFBRIDGE] Received 0x55

from rf-bridge-efm8bb1.

I have done another branch called "Protocols": 8d57177
This is using the RC switch mechanism to detect bit 0 or bit 1.
Only sniffing with command 0xA6 is implemented. Transmit will follow if 0xA6 is working.

Please make a test with your remote...

from rf-bridge-efm8bb1.

Hi... Will look at this during Friday and get back to you.

from rf-bridge-efm8bb1.

Ok, cool....... firmware loaded and tested again. This time I see consistent results with 4 codes per "button". I've marked the similar codes with 1 through 4 for ease of identification but they appear to be rolling, although each one works first time with the switch itself when pressed.

Channel 1 "On" 10 Times
AAA604068C604055 1
AAA604068BF47055 2
AAA604068733B055 3
AAA6040683B73055 4
AAA604068C604055 1
AAA604068BF47055 2
AAA604068733B055 3
AAA6040683B73055 4
AAA604068C604055 1
AAA604068BF47055 2

Channel 1 "Off" 10 times
AAA604068DE8A055 1
AAA6040682152055 2
AAA6040686821055 3
AAA6040685299055 4
AAA604068DE8A055 1
AAA6040682152055 2
AAA6040686821055 3
AAA6040685299055 4
AAA604068DE8A055 1
AAA6040682152055 2

from rf-bridge-efm8bb1.