That’s nice to hear. Thank you for testing. I am going to recommend releasing the bug-fix for the next hass release.
cheers,
David
That’s nice to hear. Thank you for testing. I am going to recommend releasing the bug-fix for the next hass release.
cheers,
David
I am back and it works perfectly!!! Thank you for amazing work @DavidLP !!!
Thank you for the tip @Dullage, worked like a charm!
Really happy that all is integrated in Home Assistant now, I can also use the RF remote and Home Assistant detects change of state perfectly.
Can you share your config for the switch. I keep getting an error.
If you didn’t use the bugfix @DavidLP posted in his reply, it will not work for you, because the fix hasn’t been yet implemented in HA. Have a look GitHub and GitHub2. They are still working on it. I hope it gets merged for 0.37.
Otherwise, there is my config for one of the switches:
- platform: pilight
switches:
etekcity1:
on_code:
protocol: clarus_switch
unit: 4
id: A2
'on': 1
off_code:
protocol: clarus_switch
unit: 4
id: A2
'off': 1
on_code_receive:
protocol: clarus_switch
unit: 4
id: A2
state: 'on'
off_code_receive:
protocol: clarus_switch
unit: 4
id: A2
state: 'off'
Hope it helps
Thanks, that works
Just wondering if anyone else is experiencing random triggers with the pilight switch?
Alphanumeric ids should start working in version 0.37.1. Also there is a new protocol option called echo
. This should be set to false if the on_code_receive
matches the on_code
(same also for off). This prevents to resend a received code, since one can assume that the hardware was toggled already.
switch_01:
on_code:
protocol: intertechno_switch
id: 58318848
unit: 2
'on': 1
on_code_receive:
- protocol: arctech_switch
id: 58318848
unit: 2
state: 'on'
echo: false
off_code:
protocol: intertechno_switch
id: 58318848
unit: 2
'off': 1
off_code_receive:
- protocol: arctech_switch
id: 58318848
unit: 2
state: 'off'
echo: false
Thank you, I’ll test when 0.37.1 is available.
Random triggers means that there is an entry in the log file that a switch switched (please check). If this is the case one could reduce the false positives by requiring a code to be received several times to be considered correct. This is a pilight library feature and can be activated in the config. E.g.: receive-repeats: 2
would only trigger anything if the code is received 2 times consecutively. All 433 remotes I came across do actually send codes several times.
I am unable to add that to my pilight config. That seems to have been removed. Any other way around this?
All possible settings are listed here. Why do you think this setting is removed? Also did you check that there is an entry in the hass logfile for the random switches?
Here is a copy of my config
{
“devices”: {},
“rules”: {},
“gui”: {},
“settings”: {
“receive-repeats”: 1,
“log-level”: 6,
“pid-file”: “/var/run/pilight.pid”,
“log-file”: “/var/log/pilight.log”,
“webserver-enable”: 1,
“webserver-root”: “/usr/local/share/pilight/”,
“webserver-http-port”: 5001,
“webserver-cache”: 1,
“port”: 5000
},
“hardware”: {
“433gpio”: {
“sender”: 0,
“receiver”: 1
}
},
“registry”: {
“pilight”: {
“firmware”: {
“version”: 11613,
“lpf”: 60920,
“hpf”: 167010
},
“version”: {
“current”: “7.0”
}
}
}
}
Then I run this and this error happens
root@raspberrypitwo:/home/pi# pilight-daemon -D
[Jan 31 08:52:05:541319] pilight-daemon: ERROR: config setting “receive-repeats” is invalid
[Jan 31 08:52:05:541432] pilight-daemon: DEBUG: garbage collected config settings library
[Jan 31 08:52:05:541467] pilight-daemon: DEBUG: garbage collected config devices library
[Jan 31 08:52:05:541495] pilight-daemon: DEBUG: garbage collected config rules library
[Jan 31 08:52:05:541522] pilight-daemon: DEBUG: garbage collected config gui library
[Jan 31 08:52:05:541560] pilight-daemon: DEBUG: freed options struct
Yes the switch is in the log fire and it is being triggered. It’s just happening when I’m not home
You are absolutetly right. I also could not find this config option in the source code. I submitted a bug report, but I guess this will not help you now.
I read somewhere that I could edit the clarus.c protocol and add rfrpt=2 in there but that doesn’t seem to work either.
Is it possible to install pilight version 6
I was able to get receive-repeats to work. However, home assistant doesn’t see anything with receive-repeats set to anything but 1. Is it that pilight.py in home assistant receives the command directly and ignore the setting. If this is the case can the receive-repeats be added to home assistant config
Yes, this is not supported yet. I only forward the first received code to not spam the event bus. I guess I will make an option for the repeats and a hass option for this. How did you activate the receive-repeats
if I may ask?
I edited the code in daemon.c under protocol->repeats++
This is part of the code. I used info from this post. https://forum.pilight.org/Thread-433-MHz-smoke-and-motion-detectors-false-alarms-receive-repeats
if (protocol->repeats < protocol->rxrpt ) {
logprintf(LOG_DEBUG, "message discarded after %d repeats as minimum # of repeats %d of %s not reached", protocol->rxrpt, protocol->repeats, protocol->id);
}
else {
logprintf(LOG_DEBUG, "caught minimum # of repeats %d of %s", protocol->repeats, protocol->id);
receiver_create_message(protocol);
}
Then I edited the .c file for my protocol and added rxrpt=2 then recompiled pilight.
After that I tested with pilight-daemon -D and the code is only broadcasted if the repeats is 2 or more.
Then on the home assistant side it wouldn’t work. So I edited pilight.py in the home assistant components folder to include repeats in the message and realized it would only receive the first code. So I dug deeper and discovered the pilight.py in the deb folder and edit the veto repeats to false. I then whitelisted repeats: 2 in home assistant and now no false triggers.
I know this will break protocols that don’t contain repeats, but I have only one protocol in use right now.
Thx. Ok good to know that this feature does not officially exist in the c library of pilight. But I can easily implement this feature in the python module.
Do you have any idea why pilight would stop receiving randomly? If I do a restart of HA it will start up again.
That is weird, did never happen to me and something similar was never reported. Can you check if the pilight c-library still works when this happens by running pilight-receive
? Also enabling info output to the log should show you (or not) if pilight codes where received in hass.
Sure that this is not related to your changes?
I can verify that pilight-receive continues to work when HA stops seeing the codes. They don’t show up in the logs either. But I will keep looking for causes. It was happening every day. But since I posted the question it has worked flawlessly. So hopefully it just keeps working.
Thanks for you help.
If you decide to implement the receive repeats let me know. And if possible have it be on a per protocol basis that would be great.