New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Nexa / Proove / Anslut 433mhz remote protocol (8?) not working #934
Comments
I should probably mention that I have performed the "Direct Hack" on my Sonoff RF bridge. |
How do I easily try out fixes to this when using Hassio?
and add a new method and some variables for supporting the pause:
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.
New protocol added:
|
I'd like to see this supported as well, especially dimming with nexa devices.
fyi manchester coding (ensures transitions,and predictable average power) |
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! |
@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? |
@fraas Good questions indeed! I kindof asked the same here: #934 (comment) |
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 |
@OttoWinter , do you have any comments to @larsenglund findings in this thread and how we can best test this? Thanks in advance |
@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! |
Great, I hope I'll be able to try it out in a couple of hours, I'll report back when done |
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: Could you double check that everything is properly setup on your end? |
@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. |
I noticed the url in repository.json points to the original esphome instead of my repo |
I changed repository.json to point towards your repo but it still pulls the official files |
Hmm, ok, not sure what to try next.. |
Any update of getting protocol 8 remotes working? Im stuck with the same issue |
@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. |
Thanks for testing! I forgot to add the variable to
esphome/components/remote_base/rc_switch_protocol.h, add this:
uint32_t sync_first_{};
after line 55.
I've fixed it in my repo.
…On Sat, Mar 28, 2020 at 7:29 PM Ubiquitous ***@***.***> 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 'sync_first_'
src/esphome/components/remote_base/rc_switch_protocol.cpp:72:13: error: 'const class esphome::remote_base::RCSwitchBase' has no member named 'sync_first_'
src/esphome/components/remote_base/rc_switch_protocol.cpp:80:14: error: 'const class esphome::remote_base::RCSwitchBase' has no member named 'sync_first_'
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#934 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABI6QJXFY4FRQZ7EEPMO5TTRJY6W7ANCNFSM4J4CVRMQ>
.
|
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.
|
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 |
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, esphome/esphome@4d31ad3#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. |
Hi, Kind of easier task, as I dont need to send anything, but still... |
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? |
I'm also having trouble with Nexa switches and the Sonoff RF bridge with the direct-hack. |
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. |
Hi there! 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.
|
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. |
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? |
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
<#934 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABQ5K4KYU4SZJSAVMCJAJV3T22W37ANCNFSM4J4CVRMQ>
.
|
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
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.
Example: For the logical datastream 0111, is sent over the air as 01101010.
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:
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:
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:
Logs (if applicable):
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):
The text was updated successfully, but these errors were encountered: