Skip to first unread message
Balu
Sep 17, 2018, 4:09:56 PM9/17/18
to SonoffUsers
Hey guys,
I've been playing with the bridge and have figured out a way to integrate a 433 MHz remote into node-red by guessing ;).
Now I'm trying to add a door/window sensor. I can see some values flowing by in debug messages, but I am not sure what to make of the values.
I'm especially wondering about the data I've been seeing with the other remote.
Typical payload is something like {"RfReceived":{"Sync":12390,"Low":410,"High":1190,"Data":"12C221","RfKey":"None"}}.
So far I've been using the Data (and after learning, the RfKey) parameter to identify buttons on the remote, but ignored the other values. Now I am wondering if they transport information too.
Does anyone know what the Sync, Low and High values are meant for?
Also are there options to recognize double-"clicks" or long presses with 433 MHz remotes for example? Or do they just send a short bursts no matter what?
As for the door sensor (https://www.banggood.com/SONOFF-DW1-433Mhz-Door-Window-Sensor-Compatible-With-RF-Bridge-For-Smart-Home-Alarm-Security-p-1227800.html) it seems it's only sending data for an "open" event, but is not able to register a closed door for example. Since that's only half the features I'd like, I guess I have to look into other sensors...
Regards,
Balu
Phil
Sep 17, 2018, 6:35:17 PM9/17/18
to SonoffUsers
Hi Balu, your using your bridge just as i am using mine, Using the data value as the subject for conditional testing. ( msg.payload.data was a node red epiphany for me) I am way outside my comfort zone with rf comms but as the low.high.and sync values do not remain constant like the data value when you repeatedly press the same button and inspect the console/mqtt output.. (test it for yourself?? press a button 5-10x and the high value will deviate for sure the others too perhaps.. been a while since i puzzled over this, but i did wonder why one value in particular would deviate by a value like 40 in a 4 digit number from press to press. So i have been working under the assumption that these values describe the signal rather than the message.
However If you have the bad luck to source 2 x sensors/devices that broadcast the same data package, try pairing one and see if the second also gets associated with the paired rfkey index of device #1 if it does it would indicate that the data element Is the prime key of the message payload. And if not then perhaps there is more going on here..
But for now I think your probably fine carrying on as you are, its been working as expected for months this end.. and if further down the road you learn more and can shed further light on the subject please do share as will I.
aside
This apparent feature of a unique data element kinda makes the pairing obsolete too. Why bother ;) Pairing with a relay enabled sonoff is one thing for network independent control, but pairing with an rf bridge? Why?? if the network is having issues you cant bypass it with a paired rf device than needs to access a network bridge.. And if the network isnt having issues then the rf device is identified by its data packet. If dealing with a code rather than an index 1..16 is really an issue?? you could always enumerate the data codes yourself and that way there is no 16 devices limit ;)
.
Thomas Walter
Sep 18, 2018, 3:22:07 AM9/18/18
to sonof...@googlegroups.com
Hey Phil,
On 18.09.18 00:35, 'Phil' via SonoffUsers wrote:
> Hi Balu, your using your bridge just as i am using mine, Using the
> data value as the subject for conditional testing. ( msg.payload.data
> was a node red epiphany for me) I am way outside my comfort zone with
[...]
Wait? If I try to use msg.payload.data, it's "undefined".
I've been using a function node like this:
// {"RfReceived":{
// "Sync":13060,
// "Low":410,"High":1270,
// "Data":"CFD238","RfKey":"None"}}
bridge=JSON.parse(msg.payload);
data = bridge.RfReceived.Data;
switch (data) {
case 'CFD238':
device = 'cmnd/DUAL/POWER1';
payload = 'TOGGLE';
break;
default:
device = 'unknown';
payload = '';
break;
}
newMsg = {'payload': payload, 'topic': device}
return [newMsg]
These new messages are then simply sent to MQTT.
> rf comms but as the low.high.and sync values do not remain constant like
> the data value when you repeatedly press the same button and inspect the
> console/mqtt output.. (test it for yourself?? press a button 5-10x and
[...]
Yeah, I wasn't sure about the values changing either. My idea was if for
example there is a value that shows the miliseconds the button was
pressed or similar. But now it seems, those are some kind of RF internal
values - like how long were low and high signals and how long did it
take to sync or something?
> This apparent feature of a unique data element kinda makes the pairing
> obsolete too. Why bother ;) Pairing with a relay enabled sonoff is one
> thing for network independent control, but pairing with an rf bridge?
> Why?? if the network is having issues you cant bypass it with a paired
> rf device than needs to access a network bridge.. And if the network
> isnt having issues then the rf device is identified by its data packet.
> If dealing with a code rather than an index 1..16 is really an issue??
> you could always enumerate the data codes yourself and that way there is
> no 16 devices limit ;)
True. The only reason for pairing I found is when you want to have the
bridge to learn signals and attach them to the "virtual" buttons of the
bridge.
Another I just thought of is that it might be easier to replace a key
fob for example. That way you'd just have to relearn the bridge and
assign the buttons, but not change the values in your node red code.
What tickles me is that the 433MHz seems to be not secured at all. If I
record the messages a sensor sends while someone is opening and closing
a window, I can easily ruin someone's day by triggering an alarm every 5
minutes or similar.
Balu
--
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
On 18.09.18 00:35, 'Phil' via SonoffUsers wrote:
> Hi Balu, your using your bridge just as i am using mine, Using the
> data value as the subject for conditional testing. ( msg.payload.data
> was a node red epiphany for me) I am way outside my comfort zone with
Wait? If I try to use msg.payload.data, it's "undefined".
I've been using a function node like this:
// {"RfReceived":{
// "Sync":13060,
// "Low":410,"High":1270,
// "Data":"CFD238","RfKey":"None"}}
bridge=JSON.parse(msg.payload);
data = bridge.RfReceived.Data;
switch (data) {
case 'CFD238':
device = 'cmnd/DUAL/POWER1';
payload = 'TOGGLE';
break;
default:
device = 'unknown';
payload = '';
break;
}
newMsg = {'payload': payload, 'topic': device}
return [newMsg]
These new messages are then simply sent to MQTT.
> rf comms but as the low.high.and sync values do not remain constant like
> the data value when you repeatedly press the same button and inspect the
> console/mqtt output.. (test it for yourself?? press a button 5-10x and
Yeah, I wasn't sure about the values changing either. My idea was if for
example there is a value that shows the miliseconds the button was
pressed or similar. But now it seems, those are some kind of RF internal
values - like how long were low and high signals and how long did it
take to sync or something?
> This apparent feature of a unique data element kinda makes the pairing
> obsolete too. Why bother ;) Pairing with a relay enabled sonoff is one
> thing for network independent control, but pairing with an rf bridge?
> Why?? if the network is having issues you cant bypass it with a paired
> rf device than needs to access a network bridge.. And if the network
> isnt having issues then the rf device is identified by its data packet.
> If dealing with a code rather than an index 1..16 is really an issue??
> you could always enumerate the data codes yourself and that way there is
> no 16 devices limit ;)
bridge to learn signals and attach them to the "virtual" buttons of the
bridge.
Another I just thought of is that it might be easier to replace a key
fob for example. That way you'd just have to relearn the bridge and
assign the buttons, but not change the values in your node red code.
What tickles me is that the 433MHz seems to be not secured at all. If I
record the messages a sensor sends while someone is opening and closing
a window, I can easily ruin someone's day by triggering an alarm every 5
minutes or similar.
Balu
--
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
Greg from Oz
Sep 18, 2018, 3:45:04 AM9/18/18
to SonoffUsers
I use node-red and I have a json node to convert.
Then I have a function node That has this code in it and I also have 8 outputs set on the node (bottom of the node) :
// Code below is for one remote control in bedroom
var on = "On";
var off = "Off";
msg1={};
// buttons 1 -2
if (msg.payload.RfReceived.Data=="D578AF"){
msg1.payload = on;
return [msg1,null,null,null]}
else if (msg.payload.RfReceived.Data=="D578A7"){
msg1.payload = off;
return [msg1,null,null,null]}
//buttons 3 -4
else if (msg.payload.RfReceived.Data=="D578AD"){
msg1.payload = on;
return [null,msg1,null,null]}
else if (msg.payload.RfReceived.Data=="D578A5"){
msg1.payload = off;
return [null,msg1,null,null]}
//buttons 5-6
else if (msg.payload.RfReceived.Data=="D578AB"){
msg1.payload = on;
return [null,null,msg1,null]}
else if (msg.payload.RfReceived.Data=="D578A3"){
msg1.payload = off;
return [null,null,msg1,null]}
//buttons 7-8
else if (msg.payload.RfReceived.Data=="D578A9"){
msg1.payload = on;
return [null,null,null,msg1]}
else if (msg.payload.RfReceived.Data=="D578A1"){
msg1.payload = off;
return [null,null,null,msg1]}
//buttons 9-10
else if (msg.payload.RfReceived.Data=="D578AE"){
msg1.payload = on;
return [null,null,null,null,msg1]}
else if (msg.payload.RfReceived.Data=="D578A6"){
msg1.payload = off;
return [null,null,null,null,msg1]}
//buttons 11-12
else if (msg.payload.RfReceived.Data=="D578AC"){
msg1.payload = on;
return [null,null,null,null,null,msg1]}
else if (msg.payload.RfReceived.Data=="D578A4"){
msg1.payload = off;
return [null,null,null,null,null,msg1]}
//buttons 13-14
else if (msg.payload.RfReceived.Data=="D578AA"){
msg1.payload = on;
return [null,null,null,null,null,null,msg1]}
else if (msg.payload.RfReceived.Data=="D578A2"){
msg1.payload = off;
return [null,null,null,null,null,null,msg1]}
//buttons 15 -16
else if (msg.payload.RfReceived.Data=="D578A9"){
msg1.payload = on;
return [null,null,null,null,null,null,null,msg1]}
else if (msg.payload.RfReceived.Data=="D578A1"){
msg1.payload = off;
return [null,null,null,null,null,null,null,msg1]}
Hope that makes sense. It works OK.
Greg from Oz
Sep 18, 2018, 3:46:24 AM9/18/18
to SonoffUsers
Also a door sensor that works with open and closed is here:
I use them and they are good.
On Tuesday, 18 September 2018 06:09:56 UTC+10, Balu wrote:
Phil
Sep 18, 2018, 12:08:13 PM9/18/18
to SonoffUsers
Check out the digoo brand of cheap chinese rf devices, even the battery-less doorbell will issue a bridge detectable data message ( I took a punt and it arrived today)
I can now flash my garage lights when the doorbell rings and im am out back with noisy tools..
Phil
Sep 18, 2018, 12:19:04 PM9/18/18
to SonoffUsers
OK thats wrong, i was picking up an unused pir signal, the batteryless doorbell is NOT tasmota friendly out of the box..
Reply all
Reply to author
Forward
0 new messages