But how do you use a RF receiver when it runs on a different computer than home assistant? And what is the disadvantage of a daemon? You cannot implement fast code interpretation in pure python .
If necessary, you can run multiple HA instances on multiple systems. Many users won’t need an extra RPI as the main software already runs on RPI.
Disadvantage of an additional daemon is that it adds complexity. It has to be installed, configured and monitored. Having everything in HA would make it much easier to use.
Analyzing RF codes in Python isn’t a problem at all. There are plenty of libraries available and this one is already used in HA to send RF codes:
Sending codes is simple. Receiving and interpreting not. You habe several 100 to 10000 Bits/s at the RPi IO. You have to check them in real time and compare them with all possible/selected protocols. This is exactly what pilight does. Please tell me a pure python module that is able to do that.
To have everything in HA is I think not how HA is ment to be. The architecture foresees to have external libraries. And there always has to be a deamon to receive RF codes in real time.
Installing pilight on the RPi is well documented and working out of the box. Precompiled libraries as well as a working 5 commands only installation are available:
git clone https://github.com/pilight/pilight
cd pilight
git checkout tags/v7.0
chmod +x setup.sh
sudo ./setup.sh
10000bits/second isn’t really a problem for a modern system as the RPI.
You can find a simple receiver demo script of the RPI RF libary here:
External libraries are ok and I think, the Home Assistant developers are also ok with an external daemon. As a user I don’t like external daemons as they increase complexity and make the whole system harder to maintain. But this is my personal opinion.
Hi. So how can I receive RF codes in HASS?
I can receive (and send) them in pilight (with the pilight sender and receiver).
I can send codes with the HASS rpi_rf platform.
But how/where can I see the received RF codes in HASS through pilight and know how to use them in automation?
Thanks
When you activated the home-assistant pilight hub then all received RF codes will be put onto the event bus. Thus you can create an event trigger as it is mentioned in the manual.
For example:
automation: trigger: platform: event event_type: pilight_received event_data: protocol: daycom
unit: 6
This example should be in the pilight hub manual.
Hi David! How can I access or get the values which were received. I can See Them in the log but have no idea to bring them into GUI… Receiving data From a weatherstation… Thanks…
Mhh I guess one has to define a general pilight sensor component, similar to the pilight switch. I do not have a 433 MHz hardware device that just sends data, so I did not implement it. If you would tell me what is being printed in your log I can try to implement such a sensor blindly (I cannot test it …), make a pull request and you test it. Since I am not home right now this will not happen before next week.
If you just want to trigger an automation rule e.g. at a certain temperature you can do this already with a template trigger.
cheers,
David
Automation/triggering is no Problem… I would like to have act temp, hum and battery in the gui…
this is what I received: INFO:homeassistant.core:Bus:Handling Event pilight_received[L]: channel=1, uuid=0000-b8-27-eb-f1f72e, battery=0, id=93, temperature=26.38, protocol=tfa, humidity=39.0
I think this is Standard on the tfa protocol
pilight sensor would be a good idea
cheers raimund
To implement this is straight forward. I will tell you when it is done.
Yes! Works perfect! Super! I think now I can also check the 433mhz light switch if it was pressed or not ! super - this is for updateing the gui when automations turned light on/off…
I think this is a question for @DavidLP
I’ve got Pilight set up and everything is working on the whole the only issue I have is this.
I have a 433 motion sensor in Pilight and when it detects movement it sends a lot of messages like this:
{
"message": {
"systemcode": 24,
"unitcode": 31,
"state": "on"
},
"origin": "receiver",
"protocol": "elro_800_switch",
"uuid": "0000-b8-27-eb-2b36a5",
"repeats": 1
}
{
"message": {
"unitcode": 521538,
"state": "closed"
},
"origin": "receiver",
"protocol": "ev1527",
"uuid": "0000-b8-27-eb-2b36a5",
"repeats": 1
}
{
"message": {
"systemcode": 24,
"unitcode": 31,
"state": "on"
},
"origin": "receiver",
"protocol": "elro_800_switch",
"uuid": "0000-b8-27-eb-2b36a5",
"repeats": 2
}
{
"message": {
"unitcode": 521538,
"state": "closed"
},
"origin": "receiver",
"protocol": "ev1527",
"uuid": "0000-b8-27-eb-2b36a5",
"repeats": 2
}
{
"message": {
"systemcode": 24,
"unitcode": 31,
"state": "on"
},
So basically the PIR spits out an elro_800_switch as “on” when there is movement and a ev1527 as “closed” when the sensor closes (or at least this is my interpretation). The problem I’m having is that if my pilight sensor in HA is set to watch the ‘state’ of the ev1527 it shows as Closed at all times and if I set it up to watch the ‘state’ of elro_800_switch it always shows as “on”. Any good ideas to workaround this problem?
Also the above is just a portion of the output that the PIR spits out for just one event of movement - is there anyway either in pilight or the HA sensor to limit how much a pilight sensor can throw into the event bus?
Thanks in advance.
Hi privatesam,
To your first question (event bus spamming):
You get a lot of messages because the binary stream fits a lot of different (or not so different …) protocolls. Usually it makes sence to compile pilight only with the procotolls of the devices you own (check troubleshooting section in the manual).
Additionally there are two other methods in place to prevent event bus spamming:
- There is a
whitelist
feature in the pilight hub component. In your case you can e.g. specify that only messages with theev1527
protocol are put onto the event bus. - Messages are often repeated, to make sure that the receiver gets it. While you see all repeated messages in the
pilight-debug
output you show, they are not put onto the HA event bus! Only the first repeat is forwarded to home-assistant.
To you second question (sensor for movement):
As you found out the motion detector only sends a message when a movement is detected, but since there is no no movement message I would not use a HASS sensor for this. A sensor has a state, but movement is not state but a trigger. So just create an automation that trriggers on the movement event, without a sensor.
cheers,
David
Thanks so much for the reply. So useful to know about the whitelist - I think I had skimmed that when I read the documentation but that perfect.
I think I understand what you mean for using the automation instead - i.e its a trigger not a state, but how do I express this in a HASS automation - what do I write for the ‘movement event’ under the trigger section? I would normally write an automation off the back of a state change in a motion sensor.
i have seen several threads on the forum about motion detectors who only send movement and no “no movement”
most people seek a way to set the sensor to “no movement” after a little time.
i dont recall if there were any succesfull results, but i think its wise to search the forum.
some off them were also about door sensors which didnt detect close, just opening.
i dont see a way to make a trigger from a movement without a sensor.
there is no event for movement, just for state change.
You want an event that is fired when the received pilight code says that the movement sensor triggered.
Thus do the following e.g.: (like I mentioned above in this thread ;-)):
automation:
trigger:
platform: event
event_type: pilight_received
event_data:
protocol: ev1527
uuid: 0000-b8-27-eb-2b36a5
...
You do not have to misuse the state change of a sensor as a trigger.
cheers,
David
are there any more events that are not mentioned in the documentation?
i looked at
to check out if there were other events, pilight recieved isnt mentioned as a possible event.
OHHHHH!!!
I see! Brilliant thanks for this. Through my ‘understanding’ of the documentation there were two ways to integrate Pilight - through a Switch and a Sensor - I didn’t realise we could address Pilight events directly like that! I guess Pilight is just pumping its events onto the HASS event bus. Gives me some more ideas!
Thanks for taking the time to explain this David - maybe I/someone should write this as a note for the Pilight documentation in case, like me, they didn’t get it.