Nexa / Proove / Anslut 433mhz remote protocol (8?) not working

[larsenglund]

Operating environment/Installation (Hass.io/Docker/pip/etc.):

Hass.io (Home Assistant 0.103.0, HassOS 2.12, ESPHome 1.14.3) on raspberry pi 3

ESP (ESP32/ESP8266, Board/Sonoff):

Sonoff RF bridge

  platform: ESP8266
  board: esp01_1m

Affected component:

https://esphome.io/components/remote_receiver.html https://esphome.io/components/remote_transmitter.html

Description of problem: The remote receiver and transmitter seems to not work for these protocols/devices: Nexa, Proove, Anslut The receiver kindof works but gives strange data. Protocol 8 has the correct timings for the bits in this protocol. But he data part on the physical link is coded so that every logical bit is sent as two physical bits, where the second one is the inverse of the first one.

'0' => '01'
'1' => '10'

Example: For the logical datastream 0111, is sent over the air as 01101010.

For more details about these protocols see https://tech.jolowe.se/home-automation-rf-protocols/ and http://tech.jolowe.se/home-automation-rf-protocol-update/

So the received data is a sync bit followed by 64 physical bits (representing 32 logical bits) followed by a pause bit. In the debug view from my esphome receiver I get the same code/data 5 times every time a button is pressed. The remote control sends the code 6 times so this is a bit odd. Also the code/data it shows me is not what I would expect:

[22:24:22][D][remote.rc_switch:243]: Received RCSwitch Raw: protocol=8 data='1101010101011010011010100101010111010101010110100110101001010101'
[22:24:22][D][remote.rc_switch:243]: Received RCSwitch Raw: protocol=8 data='1101010101011010011010100101010111010101010110100110101001010101'
[22:24:22][D][remote.rc_switch:243]: Received RCSwitch Raw: protocol=8 data='1101010101011010011010100101010111010101010110100110101001010101'
[22:24:22][D][remote.rc_switch:243]: Received RCSwitch Raw: protocol=8 data='1101010101011010011010100101010111010101010110100110101001010101'
[22:24:22][D][remote.rc_switch:243]: Received RCSwitch Raw: protocol=8 data='1101010101011010011010100101010111010101010110100110101001010101'

The data is 64 bits long so my first thought was that this must be the physical bits. But they can never start with 11. The I noticed that it is the same 32 bit pattern repeated twice. So I thought it seems to print the logical bits twice for some reason? But looking at the actual signal sent on the a scope connected to the actual transmitter gives this data:

Data from scope (S=Sync bit, P=Pause bit):
S 1010010110100101100101100101011001010101010110100110101001010101 P

Logical bits:
S 1 1 0 0 1 1 0 0 1 0 0 1 0 0 0 1 0 0 0 0 0 0 1 1 0 1 1 1 0 0 0 0  P
11001100100100010000001101110000 

Which is not the same as what ESPHome prints out. So it seems it is receiving something but not the correct data.

Sending a code is however not working. I assumed that it was printing the correct data twice and copied the 32 bit code and sent it to the transmitter but did not get a response from the receiver it was set to control. Looking at the 433Mhz spectrum with a RTL-SDR i noticed that the code esphome sends is much shorter that what the original physical remote control is sending. My guess after trying to read the source code for the remote transmitter (https://github.com/esphome/esphome/tree/adf2a463fd60c818aeeeee520f1cf7ac19095da8/esphome/components/remote_transmitter) is that is does not send each bit as two bits when using protocol 8? Also I could not find any reference to the pause bit that is sent after the code? I tried adding wait times, repeats and custom protocol to my esphome yaml but nothing works.

For code that seems to send the data correct see: https://github.com/tirithen/Arduino-ProoveSignal

Problem-relevant YAML-configuration entries:

remote_receiver:
  pin: 4
  dump: rc_switch
  tolerance: 50
  filter: 4us
  idle: 4ms

remote_transmitter:
  pin: 5
  carrier_duty_percent: 100%

switch:
  - platform: template
    name: anslut_2072266
    turn_on_action:
      - remote_transmitter.transmit_rc_switch_raw:
          # 1101010101011010011010100101010111010101010110100110101001010101
          code: '11010101010110100110101001010101'
          #protocol: 8
          repeat: 
            times: 6
            wait_time: 10250us
          protocol:
            pulse_length: 250
            sync: [1, 10]
            zero: [1, 5]
            one: [1, 1]
            inverted: false

Logs (if applicable):

[22:24:22][D][remote.rc_switch:243]: Received RCSwitch Raw: protocol=8 data='1101010101011010011010100101010111010101010110100110101001010101'
[22:24:22][D][remote.rc_switch:243]: Received RCSwitch Raw: protocol=8 data='1101010101011010011010100101010111010101010110100110101001010101'
[22:24:22][D][remote.rc_switch:243]: Received RCSwitch Raw: protocol=8 data='1101010101011010011010100101010111010101010110100110101001010101'
[22:24:22][D][remote.rc_switch:243]: Received RCSwitch Raw: protocol=8 data='1101010101011010011010100101010111010101010110100110101001010101'
[22:24:22][D][remote.rc_switch:243]: Received RCSwitch Raw: protocol=8 data='1101010101011010011010100101010111010101010110100110101001010101'

Additional information and things you've tried:

I started out with a wemos d1 mini with 433mhz RX and TX modules attached and tried to get things working on that but since I could not get it working I thought I had some hardware problem with the transmitter and ordered a Sonoff RF bridge to rule that out.

Scope image of the data used in my text above as seen on the output pin on the physical remote control (not the ESPHome):

[larsenglund]

I should probably mention that I have performed the "Direct Hack" on my Sonoff RF bridge.

[larsenglund]

I pushed button 3 ON on my remote and captured that with the scope at the output pin of the transmitter IC of the remote. From Anslut remote: Translating this to bits we get:

S 1010010110100101100101100101011001010101010110100110100101011001 P <- Button 3 On raw
S 11001100100100010000001101100010 P <- Button 3 On decoded

This was then sent from the Sonoff RF bridge using this yaml:

switch:
  - platform: template
    name: anslut_bit_test_long
    turn_on_action:
      - remote_transmitter.transmit_rc_switch_raw:
          code: '1010010110100101100101100101011001010101010110100110100101011001'
          repeat: 
            times: 6
            wait_time: 10250us
          protocol:
            pulse_length: 250
            sync: [1, 10]
            zero: [1, 5]
            one: [1, 1]
            inverted: false

And captured on the scope. From Sonoff RF bridge: Translating this to bits we get:

1101010101011010011010010101100111010101010110100110100101011001X <- sonoff button 3 on

So the Sonoff is not sending the same data as we ask it. And it's not sending the sync bit specified in the protocol (sync: [1,10]).

Pictures of my setup; The Anslut remote: The Sonoff RF bridge: (the wire going out towards the camera is connected to GND)

[larsenglund]

How do I easily try out fixes to this when using Hassio? I'm guessing transmit (line 56 in rc_switch_protocol.cpp) has to be rewritten to something like:

void RCSwitchBase::transmit(RemoteTransmitData *dst, uint64_t code, uint8_t len) const {
  dst->set_carrier_frequency(0);
  this->sync(dst);
  for (int16_t i = len - 1; i >= 0; i--) {
    if (code & (1 << i))
      this->one(dst);
    else
      this->zero(dst);
  }
  this->pause(dst);
}

and add a new method and some variables for supporting the pause:

void RCSwitchBase::pause(RemoteTransmitData *dst) const {
  if (!this->inverted_) {
    dst->mark(this->pause_high_);
    dst->space(this->pause_low_);
  } else {
    dst->space(this->pause_high_);
    dst->mark(this->pause_low_);
  }
}

Maybe this should be added as protocol 9 and a flag for sending the sync before or after the code can be introduced? And if the pause is not initialized it does not get sent.

void RCSwitchBase::transmit(RemoteTransmitData *dst, uint64_t code, uint8_t len) const {
  dst->set_carrier_frequency(0);
  if (this->sync_first_)
    this->sync(dst);
  for (int16_t i = len - 1; i >= 0; i--) {
    if (code & (1 << i))
      this->one(dst);
    else
      this->zero(dst);
  }
  if (!this->sync_first_)
    this->sync(dst);
  if (this->pause_high_ + this->pause_low_ > 0)
    this->pause(dst);
}

New protocol added:

RCSwitchBase rc_switch_protocols[10] = {RCSwitchBase(0, 0, 0, 0, 0, 0, false),
                                       RCSwitchBase(350, 10850, 350, 1050, 1050, 350, false),
                                       RCSwitchBase(650, 6500, 650, 1300, 1300, 650, false),
                                       RCSwitchBase(3000, 7100, 400, 1100, 900, 600, false),
                                       RCSwitchBase(380, 2280, 380, 1140, 1140, 380, false),
                                       RCSwitchBase(3000, 7000, 500, 1000, 1000, 500, false),
                                       RCSwitchBase(10350, 450, 450, 900, 900, 450, true),
                                       RCSwitchBase(300, 9300, 150, 900, 900, 150, false),
                                       RCSwitchBase(250, 2500, 250, 1250, 250, 250, false),
                                       RCSwitchBase(250, 2500, 250, 1250, 250, 250, false, 250, 10000)};

RCSwitchBase::RCSwitchBase(uint32_t sync_high, uint32_t sync_low, uint32_t zero_high, uint32_t zero_low,
                           uint32_t one_high, uint32_t one_low, bool inverted, uint32_t pulse_high = 0, uint32_t pulse_low = 0, bool sync_first = false)

[beikeland]

I'd like to see this supported as well, especially dimming with nexa devices. I'm leaning towards trying this, as I was using Pimatic with homeduino to handle 433mhz, so I have the arduino and rx/tx bits ready (edit, forgot link: https://github.com/TheSkorm/433mqtt )

But he data part on the physical link is coded so that every logical bit is sent as two physical bits, where the second one is the inverse of the first one.

fyi manchester coding (ensures transitions,and predictable average power)

[jappish84]

Great job at investigating @larsenglund

I'm having the same issue with protocol 8. Any success with your added protocol modifications?

[larsenglund]

Great job at investigating @larsenglund

I'm having the same issue with protocol 8. Any success with your added protocol modifications?

I haven't actually tried it out, I don't know how to test it when using hassio. I'm thinking maybe you could just point hassio to another github repo? Anyways, if someone else has the know-how to test this please do or describe how we can do it. Thanks!

[fraas]

@larsenglund. I have hassio, ESPhome and nexa devices with your issue described. Is there something I can do directly on my system to try your suggestion? Can I change the code directly, or does it have to be recompiled on my system?

[larsenglund]

@fraas Good questions indeed! I kindof asked the same here: https://github.com/esphome/issues/issues/934#issuecomment-578550448

[jappish84]

Great job at investigating @larsenglund I'm having the same issue with protocol 8. Any success with your added protocol modifications?

I haven't actually tried it out, I don't know how to test it when using hassio. I'm thinking maybe you could just point hassio to another github repo? Anyways, if someone else has the know-how to test this please do or describe how we can do it. Thanks!

Pointing hassio to another git repo seems easy enough https://www.home-assistant.io/hassio/installing_third_party_addons/

Unfortunately I don't have the know how to make a private(?) fork and compile everything, if you can do that @larsenglund (I'm thinking you can since you modified the code =)) then I'd be happy to setup a test system that points to the mod. I have a spare rf bridge I can test with aswell

[fraas]

@OttoWinter , do you have any comments to @larsenglund findings in this thread and how we can best test this?

Thanks in advance

[larsenglund]

@jappish84 I have made the changes to a fork on my account: https://github.com/larsenglund/esphome , would be awesome if you could try it out!

[jappish84]

Great, I hope I'll be able to try it out in a couple of hours, I'll report back when done

[jappish84]

@larsenglund

I tried adding the repo using https://github.com/larsenglund/esphome and https://github.com/larsenglund/esphome/hassio

but I end up getting these errors: 20-02-03 15:10:43 INFO (MainThread) [hassio.store.git] Clone add-on https://github.com/larsenglund/esphome/hassio repository 20-02-03 15:10:44 ERROR (MainThread) [hassio.store.git] Can't clone https://github.com/larsenglund/esphome/hassio repository: Cmd('git') failed due to: exit code(128) cmdline: git clone --depth=1 --recursive --shallow-submodules -v https://github.com/larsenglund/esphome/hassio /data/addons/git/fa24a7b7 stderr: 'Cloning into '/data/addons/git/fa24a7b7'... remote: Not Found fatal: repository 'https://github.com/larsenglund/esphome/hassio/' not found '. 20-02-03 15:10:44 ERROR (MainThread) [hassio.store] Can't load from repository https://github.com/larsenglund/esphome/hassio 20-02-03 15:10:44 INFO (MainThread) [hassio.store] Load add-ons from store: 63 all - 0 new - 0 remove 20-02-03 15:12:02 INFO (MainThread) [hassio.store.git] Clone add-on https://github.com/larsenglund/esphome repository 20-02-03 15:12:07 ERROR (MainThread) [hassio.utils.json] Can't read json from /data/addons/git/e8cb2065/repository.json: [Errno 2] No such file or directory: '/data/addons/git/e8cb2065/repository.json' 20-02-03 15:12:07 WARNING (MainThread) [hassio.store.data] Can't read repository information from /data/addons/git/e8cb2065/repository.json

Could you double check that everything is properly setup on your end?

[fraas]

@jappish84, you need the hassio repo for the add-on to work which @larsenglund doesnt have. I created my own github, copied the esphome repo from Lars, and the hassio from the official esphome. I am able to install the add-on, but I think it still pulls the official esphome files instead of the repo from Lars. I tried to fiddle around a bit with the config files in hassio, but I need to accept my limitations at this point and realize this is above my knowledge.

NB! https://github.com/fraas/hassio is what I tested with.

[larsenglund]

NB! https://github.com/fraas/hassio is what I tested with.

I noticed the url in repository.json points to the original esphome instead of my repo

[fraas]

I changed repository.json to point towards your repo but it still pulls the official files

[larsenglund]

I changed repository.json to point towards your repo but it still pulls the official files

Hmm, ok, not sure what to try next..

[2BWorks]

Any update of getting protocol 8 remotes working? Im stuck with the same issue

[fraas]

@2BWorks we need input from someone like @OttoWinter or some other clever guy on how to test this. I have setup an environment that could test this at any time but need to be able to compile the changes @larsenglund made to the sourcecode. I don't have the knowledge on how to do this. The best would have been if someone could compile the changes and give us a file to replace on our system running the official GA version so we could test it.

[larsenglund]

Thanks for testing! I forgot to add the variable to esphome/components/remote_base/rc_switch_protocol.h, add this: uint32_t syncfirst{}; after line 55. I've fixed it in my repo.

On Sat, Mar 28, 2020 at 7:29 PM Ubiquitous notifications@github.com wrote:

Any success with this one? I pip installed this repo for testing directly in esphome cli. It spit out a few "default argument given for parameter" errors for parameter 8, 9 and 10 here:

RCSwitchBase::RCSwitchBase(uint32_t sync_high, uint32_t sync_low, uint32_t zero_high, uint32_t zero_low, uint32_t one_high, uint32_t one_low, bool inverted, uint32_t pulse_high = 0, uint32_t pulse_low = 0, bool sync_first = false)

I got rid of those errors by removing the default values on parameters 8, 9 and 10 after reading this https://stackoverflow.com/questions/2545720/error-default-argument-given-for-parameter-1/2545733 Now it is outputting three errors, that I don't know what to do with:

src/esphome/components/remote_base/rc_switch_protocol.cpp:32:7: error: class 'esphome::remote_base::RCSwitchBase' does not have any field named 'syncfirst'

src/esphome/components/remote_base/rc_switch_protocol.cpp:72:13: error: 'const class esphome::remote_base::RCSwitchBase' has no member named 'syncfirst'

src/esphome/components/remote_base/rc_switch_protocol.cpp:80:14: error: 'const class esphome::remote_base::RCSwitchBase' has no member named 'syncfirst'

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/esphome/issues/issues/934#issuecomment-605500426, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABI6QJXFY4FRQZ7EEPMO5TTRJY6W7ANCNFSM4J4CVRMQ .

[Ubiquitous-X]

That indeed made the yaml compile and upload (after removing two non breaking spaces at the end of line 56. Also removing the default values on the parameters pulse_high, pulse_low and sync_first on line 22 and 23 in rc_switch_protocol.cpp was necessary.

That made my Anslut wall sockets to work! BUT, I don't get it at all why my Nexa devices are still not turning on. They are running the exactly same protocol as Anslut, yes? I am able to run both on the same sketch on Arduino for example. I get perfect, reliable readings when sniffing the codes with remote_reciever and I just don't get it why only the Nexas refuse to turn on. I also tried with 5 repeats, as according to https://tech.jolowe.se/home-automation-rf-protocols/ but with no go.

switch:
  - platform: template
    name: nexa_anslut_testing
    turn_on_action:
      - remote_transmitter.transmit_rc_switch_raw:
          code: '1001010110100110010101010101011010101010101010010110100110101001'
          repeat:
            times: 5
            wait_time: 10250us
          protocol:
            pulse_length: 250
            sync: [1, 10]
            zero: [1, 5]
            one: [1, 1]
            inverted: false

[larsenglund]

Awesome that it works with Anslut! How do we get this fix out to users running Hassio?

Strange indeed that it does not work for Nexa as they seem to be identical. But the author of https://tech.jolowe.se/home-automation-rf-protocols/ has indeed separated out Nexa from Proove/Anslut when he implemented Arduino libraries for them. I guess there is a reason for that and that the answer lies in the code difference between https://github.com/JoakimWesslen/Tx433 and https://github.com/JoakimWesslen/Tx433_Nexa

[Ubiquitous-X]

1.14.3 of Esphome was released in November 2019, and since then there have been some pushes to the official repo, that says it added support for Anslut/Proove/Nexa, for example, https://github.com/esphome/esphome/commit/4d31ad3bdc7d7182de4abb22079a9629eba50321#diff-42554634b20ea6929b3938861c12fe86

I have no success with the new changes in the official repo either, though. For instance, it doesn't add the sync_first thingy that I believe is necessary. The only thing I have got to work is the files from your repo. (Still not Nexa though, but Anslut). But how to get that in the official repo is beyond my competence. And I don't know how far into the future we are for a new version of Esphome to release for Hassio. But I think that with the help of this thread and some good tinkering people have a good chance to get their Scandinavian devices running from Esphome and Hassio.

[flaotte]

Hi, does anyone made nexa switches to come up in esphome? I want to use nexa radio switches to control scenes, it comes as raw value (with duplicated code), but I am not able to get it reported.

Kind of easier task, as I dont need to send anything, but still... Any ideas?

[jappish84]

Hey, an idea that's maybe stupid. Since the remote receiver can dump basically any code you throw at it, would it possible to use the received code and relay it to say an mqtt message within the scope of esphome? I know that the remote transmit function wouldn't be able to control anything until the protocols are matched correctly, but this would at least let us use any unsupported/broken protocols as triggers via mqtt, no?

[jonasblomq]

I'm also having trouble with Nexa switches and the Sonoff RF bridge with the direct-hack. From what I can see from a simple SDR radio, the Sonoff sends out packages that are roughly the correct size..

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[GruffyPuffy]

Hi there! Long time since this was updated. However, I did some work on getting the Nexa protocol into ESPHome (for the Sonoff RF-bridge with DIRECT HACK applied) and for me it works pretty nice right now. I have it in a github-fork, https://github.com/GruffyPuffy/esphome - in the Nexa433-branch => https://github.com/GruffyPuffy/esphome/tree/Nexa433. I will hopefully get this as a PR some day, but I would like some tests on it first.

So, I have, instead of using rc_switch, created a new protocol class called "nexa". This is easier as then one can set dimmer-levels etc as you like. I am now using this with Home Assistant with great success...hopefully someone can help me test it further.

This is from my YML-file for sample of how to use it. It contains one binary sensor that is the "receiver of a remote key-press", and two lights (one standard and one dimmable).

esphome:
   name: nexa_bridge
   platform: ESP8266
   board: esp01_1m

wifi:
   ssid: "YOUR SSID"
   password: "YOUR PASSWD"

# Enable logging
logger:

web_server:
  port: 80

# Enable Home Assistant API
api:
  password: ""

ota:
  password: ""

remote_receiver:
   pin:
     number: 4
   dump:
   - nexa
   filter: 50us
   idle: 4ms

remote_transmitter:
  pin: 5
  carrier_duty_percent: 100%

binary_sensor:
  - platform: remote_receiver
    name: "Nexa Remote 2 Open"
    internal: yes
    nexa:
      device: 0x4C1C12
      state: 1
      group: 0
      channel: 1
      level: 0
    on_press:
      - binary_sensor.template.publish:
          id: NexaRemote2
          state: ON
  - platform: remote_receiver
    name: "Nexa Remote 2 Closed"
    internal: yes
    nexa:
      device: 0x4C1C12
      state: 0
      group: 0
      channel: 1
      level: 0
    on_press:
      - binary_sensor.template.publish:
          id: NexaRemote2
          state: OFF
  - platform: template
    name: "NexaRemote2 State"
    device_class: window
    id: NexaRemote2

output:
  - platform: template
    id: tilda_slinga_output
    type: binary

    write_action:
      - if:
          condition:
            light.is_on: tilda_slinga_light
          then:
            remote_transmitter.transmit_nexa:
              device: 0x38DDB4A
              state: 1
              group: 0
              channel: 15
              level: 0
              repeat: 5
          else:
            remote_transmitter.transmit_nexa:
              device: 0x38DDB4A
              state: 0
              group: 0
              channel: 15
              level: 0
              repeat: 5

  - platform: template
    id: vardagsrum_dimable_slinga_output
    type: float

    write_action:
      - if:
          condition:
            lambda: return (state > 0);
          then:
            remote_transmitter.transmit_nexa:
              device: 0x19A5470
              state: 2
              group: 0
              channel: 0
              level: !lambda return state*15;
              repeat: 5
          else:
            remote_transmitter.transmit_nexa:
              device: 0x19A5470
              state: 0
              group: 0
              channel: 0
              level: 0
              repeat: 5

light:
  - platform: binary
    name: "Tilda Slinga"
    id: tilda_slinga_light
    output: tilda_slinga_output

  - platform: monochromatic
    name: "Vardagsrum Slinga"
    id: vardagsrum_dimable_slinga_light
    output: vardagsrum_dimable_slinga_output

[fraas]

I would love to try this out, but I can't add your version to the add-on repository.

[GruffyPuffy]

I would love to try this out, but I can't add your version to the add-on repository.

It is a fork of the ESPHome source code. In order to test now you would have to follow the description above to clone&build on your local computer. Then manually flash a Sonoff RF-bridge (that is hacked with the direct-RF hack). If/when this PR (I have it started and trying) is accepted, it will be part of standard ESPHome releases and installation would be simpler.

[fraas]

Thanks. Built a local copy of your branch and was able to get a standard Nexa door/window sensor to work. However, other RF sensors did not work as the protocol type is set to nexa instead of rc_swtich. Does this mean that this setup requires its own RF bridge only for Nexa devices?

[flaotte]

I use only Nexa wall switched, somehow i made it to work and it's very reliable. So i prefer not to upgrade any version/configuration.

On Mon, Aug 2, 2021, 16:57 fraas @.***> wrote:

Thanks. Built a local copy of your branch and was able to get a standard Nexa door/window sensor to work. However, other RF sensors did not work as the protocol type is set to nexa instead of rc_swtich. Does this mean that this setup requires its own RF bridge only for Nexa devices?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/esphome/issues/issues/934#issuecomment-891094325, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABQ5K4KYU4SZJSAVMCJAJV3T22W37ANCNFSM4J4CVRMQ .