If it is something as simple as that, I will be happy, but also that would be incredibly ironic! I was thinking last night as I was going to bed that maybe I am looking I’m the wrong place. That maybe it had to do with the binding itself. I am not in front of my setup and won’t be till later, but I was wondering if it had something to do with the fact that I have exec1 installed as well. Wait, now that I said that I think I know exactly what is wrong! (Insert lightbulb here) I’m not going to say until I check it, but will report back for posterity. Thanks again!
Wow, so yeah, I was thinking WAY too hard about this. As I am sure you have probably already figured out, I didn’t have the exec binding installed!
I have a “good” reason 
When I initially installed, I had installed the exec1 binding as I was going to use that but later decided to just move forward with the exec 2 version. I totally never went back in and changed it! I can’t believe that. I know we have all done it, but it still sucks! Hours of work until my eyes were crossed and it was something so simple. It is on now though, this was all I needed to figure out to get fully migrated. Thanks again!
Mike
@Josar OK, so I have my entire setup to where it is working. I even had quite a significant amount of delay (as compared to my OH1, exec1 binding). I just removed the thread::sleep(500) items and it is near instant (I don’t have a lot going on and my hardware can seem to keep up just fine without it, except on the rule that turns on all my basement lights (or OFF). Needed to add a tiny bit of sleep (as well as fix ssh multithreading) to make them consistent.
However, in dealing with certain instances where I have to issue a command multiple times to get it to work, I came across some weirdness in my logs. Looking back at your response comparing my logs with yours, I noticed it is present there but on your log I don’t see it. (Note, my commands not working sometimes very well could be due to my transmitter because I see in the log the command fires, so that isn’t really my concern here, in fact, these logs still show up this way with my ssh commands (zigbee) to my rooted wink hub.
Anyway, what I am seeing is it looks like my devices are getting change from ON to OFF then OFF to ON immediately (or vice versa). And I have no clue why this would be happening. Hoping you or someone else can see what I may be missing:
Whenever I only turn an Item on (or off), each time I get the following in the logs:
12:30:02.975 [INFO ] [smarthome.event.ItemCommandEvent ] - Item 'rf_plug_LR_lamp' received command ON
12:30:03.016 [INFO ] [pse.smarthome.model.script.RF Outlets] - Result:Sending Code: 5330236. PIN: 0. Pulse Length: 189
12:30:03.088 [INFO ] [smarthome.event.ItemStateChangedEvent] - rf_plug_LR_lamp changed from OFF to ON
12:30:03.240 [INFO ] [smarthome.event.ItemCommandEvent ] - Item 'Outlet_Power_Args_RF' received command 5330371
12:30:03.307 [INFO ] [smarthome.event.ItemStateChangedEvent] - Outlet_Power_Args_RF changed from 5330236 to 5330371
12:30:03.422 [INFO ] [smarthome.event.ItemStateChangedEvent] - Outlet_Power_RF changed from OFF to ON
12:30:03.482 [INFO ] [smarthome.event.ItemStateChangedEvent] - Outlet_Power_RF changed from ON to OFF
12:30:03.544 [INFO ] [smarthome.event.ItemStateChangedEvent] - Outlet_Power_Out_RF changed from Sending Code: 5330236. PIN: 0. Pulse Length: 189 to Sending Code: 5330371. PIN: 0. Pulse Length: 189
Here is the result from the OFF command being sent afterward as well:
12:30:33.688 [INFO ] [smarthome.event.ItemCommandEvent ] - Item 'rf_plug_LR_lamp' received command OFF
12:30:33.741 [INFO ] [pse.smarthome.model.script.RF Outlets] - Result:Sending Code: 5330371. PIN: 0. Pulse Length: 189
12:30:33.779 [INFO ] [smarthome.event.ItemStateChangedEvent] - rf_plug_LR_lamp changed from ON to OFF
12:30:33.929 [INFO ] [smarthome.event.ItemCommandEvent ] - Item 'Outlet_Power_Args_RF' received command 5330380
12:30:33.996 [INFO ] [smarthome.event.ItemStateChangedEvent] - Outlet_Power_Args_RF changed from 5330371 to 5330380
12:30:34.068 [INFO ] [smarthome.event.ItemStateChangedEvent] - Outlet_Power_RF changed from OFF to ON
12:30:34.128 [INFO ] [smarthome.event.ItemStateChangedEvent] - Outlet_Power_RF changed from ON to OFF
12:30:34.188 [INFO ] [smarthome.event.ItemStateChangedEvent] - Outlet_Power_Out_RF changed from Sending Code: 5330371. PIN: 0. Pulse Length: 189 to Sending Code: 5330380. PIN: 0. Pulse Length: 189
Here is the result on an ON command, still using the exec command, but invoking a different script (callbacks can be ignored, just feedback from the winkhub that don’t affect anything really)
12:32:37.655 [INFO ] [smarthome.event.ItemCommandEvent ] - Item 'zigbee_bulb_hall_light' received command ON
12:32:37.661 [INFO ] [e.model.script.Zigbee Bulb Hall Light] - Result:Update device with master ID 7, setting value OFF for attribute 1
Waiting for 1 callbacks...
Received a myNodeDataCallback from Zigbee
Source: aprontest
Event: RADIO_EVT_NODE_UPDATE
Status: FLX_OK
Node: 7
12:32:37.751 [INFO ] [smarthome.event.ItemCommandEvent ] - Item 'Bulb_Power_Args_Zig' received command -m 6 -u -t 1 -v ON
12:32:38.124 [INFO ] [smarthome.event.ItemStateChangedEvent] - zigbee_bulb_hall_light changed from OFF to ON
12:32:38.189 [INFO ] [smarthome.event.ItemStateChangedEvent] - Bulb_Power_Args_Zig changed from -m 7 -u -t 1 -v OFF to -m 6 -u -t 1 -v ON
12:32:38.265 [INFO ] [smarthome.event.ItemStateChangedEvent] - Bulb_Power_Zig changed from OFF to ON
12:32:40.101 [INFO ] [smarthome.event.ItemStateChangedEvent] - Bulb_Power_Zig changed from ON to OFF
12:32:40.167 [INFO ] [smarthome.event.ItemStateChangedEvent] - Bulb_Power_Out_Zig changed from Update device with master ID 7, setting value OFF for attribute 1
rfoutlets.items
Switch rf_plug_LR_lamp <lightbulb>
Switch rf_plug_DR_lamp <lightbulb>
Switch rf_plug_BR_lamp <lightbulb>
Switch Outlet_Power_RF { channel="exec:command:outlet-power:run" }
String Outlet_Power_Args_RF { channel="exec:command:outlet-power:input" }
String Outlet_Power_Out_RF { channel="exec:command:outlet-power:output" }
zigbee_bulbs.items
Switch zigbee_bulb_Lydias_lamp <lightbulb>
Switch zigbee_bulb_desk_lamp <lightbulb>
Switch zigbee_bulb_front_porch <lightbulb>
Switch zigbee_bulb_basement_door <lightbulb>
Switch zigbee_bulb_basement_cree_1 <lightbulb>
Switch zigbee_bulb_basement_cree_2 <lightbulb>
Switch zigbee_bulb_basement_cree_3 <lightbulb>
Switch zigbee_bulb_hall_light <lightbulb>
Switch zigbee_bulb_basement_all <lightbulb>
Switch Bulb_Power_Zig { channel="exec:command:zigbee-bulb-power:run" }
String Bulb_Power_Args_Zig { channel="exec:command:zigbee-bulb-power:input" }
String Bulb_Power_Out_Zig { channel="exec:command:zigbee-bulb-power:output" }
exec.things
Thing exec:command:outlet-power [
command="/home/pi/python_scripts/automation/v2/codesend %2$s",
interval=0,
autorun=true]
Thing exec:command:zigbee-bulb-power [
command="/home/pi/oh_custom_scripts/wink-as-pi.sh %2$s",
interval=0,
autorun=true]
Thing exec:command:zigbee-outlet-power [
command="/home/pi/oh_custom_scripts/wink-as-pi.sh %2$s",
interval=0,
autorun=true]
home.rules
rule "Front Porch"
when
Item zigbee_bulb_front_porch received command
then
if(receivedCommand == ON){
Bulb_Power_Args_Zig.sendCommand("-m 7 -u -t 1 -v ON")
} else {
Bulb_Power_Args_Zig.sendCommand("-m 7 -u -t 1 -v OFF")
}
logInfo("Zigbee Bulb Front Porch","Result:" + Bulb_Power_Out_Zig.state)
end
//****************************************************
rule "Living Room Lamp"
when
Item rf_plug_LR_lamp received command
then
if(receivedCommand == ON){
Outlet_Power_Args_RF.sendCommand("5330371")
} else {
Outlet_Power_Args_RF.sendCommand("5330380")
}
logInfo("RF Outlets","Result:" + Outlet_Power_Out_RF.state)
end
//****************************************************
rule "Desk Lamp"
when
Item zigbee_bulb_desk_lamp received command
then
if(receivedCommand == ON){
Bulb_Power_Args_Zig.sendCommand("-m 9 -u -t 1 -v ON")
} else {
Bulb_Power_Args_Zig.sendCommand("-m 9 -u -t 1 -v OFF")
}
logInfo("Zigbee Bulb Desk Lamp","Result:" + Bulb_Power_Out_Zig.state)
end
//****************************************************
rule "Dining Room Lamp"
when
Item rf_plug_DR_lamp received command
then
if(receivedCommand == ON){
Outlet_Power_Args_RF.sendCommand("5332227")
} else {
Outlet_Power_Args_RF.sendCommand("5332236")
}
logInfo("Dining Room Outlet","Result:" + Outlet_Power_Out_RF.state)
end
//****************************************************
rule "Hall Light"
when
Item zigbee_bulb_hall_light received command
then
if(receivedCommand == ON){
Bulb_Power_Args_Zig.sendCommand("-m 6 -u -t 1 -v ON")
} else {
Bulb_Power_Args_Zig.sendCommand("-m 6 -u -t 1 -v OFF")
}
logInfo("Zigbee Bulb Hall Light","Result:" + Bulb_Power_Out_Zig.state)
end
//****************************************************
rule "Lydias Lamp"
when
Item zigbee_bulb_Lydias_lamp received command
then
if(receivedCommand == ON){
Bulb_Power_Args_Zig.sendCommand("-m 1 -u -t 1 -v ON")
} else {
Bulb_Power_Args_Zig.sendCommand("-m 1 -u -t 1 -v OFF")
}
logInfo("Zigbee Bulbs Lydias Lamp","Result:" + Bulb_Power_Out_Zig.state)
end
//****************************************************
rule "Bedroom Lamp"
when
Item rf_plug_BR_lamp received command
then
if(receivedCommand == ON){
Outlet_Power_Args_RF.sendCommand("5330227")
} else {
Outlet_Power_Args_RF.sendCommand("5330236")
}
logInfo("Bedroom Outlet","Result:" + Outlet_Power_Out_RF.state)
end
//****************************************************
rule "Basement Door Light"
when
Item zigbee_bulb_basement_door received command
then
if(receivedCommand == ON){
Bulb_Power_Args_Zig.sendCommand("-m 5 -u -t 1 -v ON")
} else {
Bulb_Power_Args_Zig.sendCommand("-m 5 -u -t 1 -v OFF")
}
logInfo("Zigbee Bulb Basement Door","Result:" + Bulb_Power_Out_Zig.state)
end
//****************************************************
rule "Heater"
when
Item zigbee_outlet_heater received command
then
if(receivedCommand == ON){
Outlet_Power_Args_Zig.sendCommand("-m 10 -u -t 1 -v ON")
} else {
Outlet_Power_Args_Zig.sendCommand("-m 10 -u -t 1 -v OFF")
}
logInfo("Zigbee Outlet Heater","Result:" + Outlet_Power_Out_Zig.state)
end
//****************************************************
rule "All Basement Lights"
when
Item zigbee_bulb_basement_all received command
then
if(receivedCommand == ON){
Outlet_Power_Args_Zig.sendCommand("-m 5 -u -t 1 -v ON") //basement door
zigbee_bulb_basement_door.postUpdate("ON")
Thread::sleep(50)
Outlet_Power_Args_Zig.sendCommand("-m 2 -u -t 1 -v ON") //cree overhead 1
Thread::sleep(50)
Outlet_Power_Args_Zig.sendCommand("-m 3 -u -t 1 -v ON") //cree overhead 2
Thread::sleep(50)
Outlet_Power_Args_Zig.sendCommand("-m 4 -u -t 1 -v ON") //cree overhead 3
} else {
Outlet_Power_Args_Zig.sendCommand("-m 5 -u -t 1 -v OFF") //basement door
zigbee_bulb_basement_door.postUpdate("OFF")
Thread::sleep(50)
Outlet_Power_Args_Zig.sendCommand("-m 2 -u -t 1 -v OFF") //cree overhead 1
Thread::sleep(50)
Outlet_Power_Args_Zig.sendCommand("-m 3 -u -t 1 -v OFF") //cree overhead 2
Thread::sleep(50)
Outlet_Power_Args_Zig.sendCommand("-m 4 -u -t 1 -v OFF") //cree overhead 3
}
logInfo("Zigbee All Basement Lights","Result:" + Outlet_Power_Out_Zig.state)
end
I know it is a big long, but clean enough I hope to be able to understand what is going on.
Pinging @rlkoshak as well in case it is not necessarily related to exec…
It seems that it is just the item state that is changing, but it still doesn’t look right. Thanks!
@shelzmike you can reduce this to 2 rules one for the 433 devices and one for the zigbee devices. See my updated examples.
The item changes when the Skript Starts and when it ends. This is how it should be. What is your question here?
I’m on my phone and don’t have time to fully read your code but based on the behavior I think you are seeing the expected behavior of the run channel. The switch linked to the run channel will only be ON while they script is running. I suspect your script only stays running for a few milliseconds which is why it immediately goes back to off.
Without fully analyzing your code, I suspect what you will want to do is use a proxy item or the item linked to the output channel to represent the state of the light.
I own an apology. I have been trying to wrap my head around the new exec binding and OH2 for so many hours this past week that I think I overlooked a simple explanation here. What I notice now, it is not the actual device that is changing state from OFF to ON then from ON to OFF, instead it is the item that is a proxy? (Is this what an item proxy is, as reference by @rlkoshak in his response? In any event, whatever it is called, I now finally see the logic in it and am seeing that it wasn’t what I was thinking was happening (I thought the actual thing acted on was turning OFF to ON then ON to OFF).
I saw the reference your much more condensed rule, leveraging groups and plan on implementing that; however, as a learning exercise I did it the way I did so that I could clearly see what was going on.
Thanks again for the responses and the work you have done on this to help others. It is appreciated.
Hello,
i have just one problem. Everything works fine but when im pushing the button on the webinterface nothing happens. I changed the code to 10101 and the correct folder for my raspberry-remote file in the things file. Does anybody know what to do?
import java.util.concurrent.locks.ReentrantLock
val ReentrantLock transmitter = new ReentrantLock
rule "Single Plug"
when
Member of Gplugs received command
// Item Power_Plug_Socket_1 received command or
// Item Power_Plug_Socket_2 received command or
// Item Power_Plug_Socket_3 received command or
// Item Power_Plug_Socket_4 received command
then
logInfo("Power_Plug", "Member " + triggeringItem.name + " to " + receivedCommand)
try {
// Lock transmitter so other executed rules dont't use it at the same time.
// Concurrent calls of the rule will wait till the resource is free again.
transmitter.lock()
// Get the item which triggered the rule
// Split the name and get the second part, the number to set as command.
val num = triggeringItem.name.toString.split("Power_Plug_Socket_").get(1)
// Set the command which should be executed to the output channel
// Auto trigger will then execute the Thing.
if(receivedCommand == ON){
Remote_Send_Args.sendCommand("10101 " + num +" 1")
}else{
Remote_Send_Args.sendCommand("10101 " + num +" 0")
}
// Wait for the command to complete
while(Remote_Send.state != OFF){
Thread::sleep(100)
}
// Mulltiple trigger do not work if there is no break here
// maybe external skript needs some time to properly free resources.
Thread::sleep(400)
logInfo("Power_Plug", Remote_Send_Out.state.toString.replaceAll("\r|\n"," ") )
}catch(Throwable t) {}
finally {
// Free the resource for the next call.
transmitter.unlock()
}
end
Thing exec:command:remote-send [
command="sudo /opt/raspberry-remote/send %2$s",
interval=0,
autorun=true]
Don’t use sudo.
And if you need, read the whole tutorial again. As it explains how to add openhab to the gpio group and enable gpio accces without sudo.
Tank you, but nothing helps. I removed the sudo and the command works also when im typing it manually without sudo. I already did the tutorial twice.
It works 
Thank you a Lot
Hi Josar,
first of all, thanks a lot for your great tutorials. I am currently trying to implement an 433MHz controlled LED-strip and I am facing 2 problems:
My current setup: I have a raspberry pi3 with 433MHz tx and 433MHz rx module installed.
- Sending the code works but unfortunately the LED strip doesn’t switch on. So I used “RFSniffer -v” to get the code from the original remote control:
Received 5234687
=============================================
=============================================
GENERAL
=======
Received 5234687
Bitlength 24
Protocol 1
Delay(pulse length in us) 335
(delay provided from rc-switch)
STATISTICS
==========
Duration of data bits in pulse train : 32145
Data bit duration = 1339 and standard deviation = 3.46
Coefficient of variation of data-bit duration = 0.26 % (should be less than 10%)
Do not use the rest of the information if big coefficient of variation
Long-to-short duration ratio for data bits (rounded) = 3
Sync bit (in multiples of the pulseLength) = 1 16
Proposed protocol for RCswitch
{ 335, { 1, 16 }, { 1, 3 }, { 3, 1 }, false }
STATISTICS OF VARIATION BY LEVELS
=================================
(Differences here are probably artifacts from signal creation or detection)
(This might be completely ignored, but pay attention to them if big differences are present and emission does not work)
number of bits set (in 5234687): 20
longup, longdown, shortup, shortdown
1008, 994, 342, 331
this might be useful for tweaking emmitting algorithms
=============================================
RAW SIGNAL (us)
===============
first level down
5217
336 998 1009 334 344 990 345 995 1015 329 1011 326 1013 325 1011 332
1011 325 1010 329 345 995 1017 326 1011 325 1011 332 1004 334 1007 331
1005 331 1012 333 1009 326 1005 335 1006 333 1005 334 1003 336 1000 346
334
=============================================
Received 5234687
=============================================
=============================================
GENERAL
=======
Received 5234687
Bitlength 24
Protocol 1
Delay(pulse length in us) 335
(delay provided from rc-switch)
STATISTICS
==========
Duration of data bits in pulse train : 32147
Data bit duration = 1339 and standard deviation = 3.46
Coefficient of variation of data-bit duration = 0.26 % (should be less than 10%)
Do not use the rest of the information if big coefficient of variation
Long-to-short duration ratio for data bits (rounded) = 3
Sync bit (in multiples of the pulseLength) = 1 16
Proposed protocol for RCswitch
{ 335, { 1, 16 }, { 1, 3 }, { 3, 1 }, false }
STATISTICS OF VARIATION BY LEVELS
=================================
(Differences here are probably artifacts from signal creation or detection)
(This might be completely ignored, but pay attention to them if big differences are present and emission does not work)
number of bits set (in 5234687): 20
longup, longdown, shortup, shortdown
1010, 1000, 341, 328
this might be useful for tweaking emmitting algorithms
=============================================
RAW SIGNAL (us)
===============
first level down
5216
343 995 1009 330 337 1000 345 1006 1016 321 1012 328 1015 322 1014 326
1013 323 1013 329 339 1002 1009 329 1013 327 1009 329 1010 325 1013 327
1010 332 1009 330 1011 327 1014 323 1010 331 1004 330 1007 336 1007 337
334
=============================================
Received 5234687
=============================================
=============================================
GENERAL
=======
Received 5234687
Bitlength 24
Protocol 1
Delay(pulse length in us) 335
(delay provided from rc-switch)
STATISTICS
==========
Duration of data bits in pulse train : 32136
Data bit duration = 1339 and standard deviation = 3.00
Coefficient of variation of data-bit duration = 0.22 % (should be less than 10%)
Do not use the rest of the information if big coefficient of variation
Long-to-short duration ratio for data bits (rounded) = 3
Sync bit (in multiples of the pulseLength) = 1 16
Proposed protocol for RCswitch
{ 335, { 1, 16 }, { 1, 3 }, { 3, 1 }, false }
STATISTICS OF VARIATION BY LEVELS
=================================
(Differences here are probably artifacts from signal creation or detection)
(This might be completely ignored, but pay attention to them if big differences are present and emission does not work)
number of bits set (in 5234687): 20
longup, longdown, shortup, shortdown
1008, 994, 341, 331
this might be useful for tweaking emmitting algorithms
=============================================
RAW SIGNAL (us)
===============
first level down
5220
341 992 1011 331 340 998 340 997 1014 327 1011 328 1015 326 1007 334
1011 325 1012 328 343 992 1012 332 1011 330 1007 333 1005 331 1006 332
1004 335 1004 333 1007 333 1006 336 1002 335 1004 331 1006 332 1005 341
333
=============================================
When I send the code via codesend: /home/pi/433Utils/RPi_utils/codesend 5234687
The Sniffer gets the following output:
Received 5234687
=============================================
=============================================
GENERAL
=======
Received 5234687
Bitlength 24
Protocol 1
Delay(pulse length in us) 380
(delay provided from rc-switch)
STATISTICS
==========
Duration of data bits in pulse train : 36491
Data bit duration = 1520 and standard deviation = 2.24
Coefficient of variation of data-bit duration = 0.15 % (should be less than 10%)
Do not use the rest of the information if big coefficient of variation
Long-to-short duration ratio for data bits (rounded) = 3
Sync bit (in multiples of the pulseLength) = 1 29
Proposed protocol for RCswitch
{ 380, { 1, 29 }, { 1, 3 }, { 3, 1 }, false }
STATISTICS OF VARIATION BY LEVELS
=================================
(Differences here are probably artifacts from signal creation or detection)
(This might be completely ignored, but pay attention to them if big differences are present and emission does not work)
number of bits set (in 5234687): 20
longup, longdown, shortup, shortdown
1104, 1114, 403, 416
this might be useful for tweaking emmitting algorithms
=============================================
RAW SIGNAL (us)
===============
first level down
10924
403 1113 1106 412 404 1115 403 1113 1106 411 1106 412 1106 413 1104 413
1107 415 1106 416 404 1118 1104 417 1106 415 1106 416 1105 419 1103 418
1102 419 1105 418 1102 420 1106 417 1102 420 1102 420 1102 418 1101 422
399
=============================================
Received 5234687
=============================================
=============================================
GENERAL
=======
Received 5234687
Bitlength 24
Protocol 1
Delay(pulse length in us) 380
(delay provided from rc-switch)
STATISTICS
==========
Duration of data bits in pulse train : 36505
Data bit duration = 1521 and standard deviation = 1.41
Coefficient of variation of data-bit duration = 0.09 % (should be less than 10%)
Do not use the rest of the information if big coefficient of variation
Long-to-short duration ratio for data bits (rounded) = 3
Sync bit (in multiples of the pulseLength) = 1 29
Proposed protocol for RCswitch
{ 380, { 1, 29 }, { 1, 3 }, { 3, 1 }, false }
STATISTICS OF VARIATION BY LEVELS
=================================
(Differences here are probably artifacts from signal creation or detection)
(This might be completely ignored, but pay attention to them if big differences are present and emission does not work)
number of bits set (in 5234687): 20
longup, longdown, shortup, shortdown
1097, 1123, 398, 423
this might be useful for tweaking emmitting algorithms
=============================================
RAW SIGNAL (us)
===============
first level down
10928
395 1125 1098 420 401 1121 399 1122 1102 422 1099 421 1099 422 1099 424
1098 421 1099 423 397 1124 1099 423 1098 422 1098 425 1096 423 1097 425
1096 425 1097 425 1096 425 1095 425 1096 426 1095 425 1096 426 1096 424
394
=============================================
Received 5234687
=============================================
=============================================
GENERAL
=======
Received 5234687
Bitlength 24
Protocol 1
Delay(pulse length in us) 380
(delay provided from rc-switch)
STATISTICS
==========
Duration of data bits in pulse train : 36482
Data bit duration = 1520 and standard deviation = 7.62
Coefficient of variation of data-bit duration = 0.50 % (should be less than 10%)
Do not use the rest of the information if big coefficient of variation
Long-to-short duration ratio for data bits (rounded) = 3
Sync bit (in multiples of the pulseLength) = 1 29
Proposed protocol for RCswitch
{ 380, { 1, 29 }, { 1, 3 }, { 3, 1 }, false }
STATISTICS OF VARIATION BY LEVELS
=================================
(Differences here are probably artifacts from signal creation or detection)
(This might be completely ignored, but pay attention to them if big differences are present and emission does not work)
number of bits set (in 5234687): 20
longup, longdown, shortup, shortdown
1094, 1128, 385, 426
this might be useful for tweaking emmitting algorithms
=============================================
RAW SIGNAL (us)
===============
first level down
10930
355 1130 1095 424 396 1126 396 1126 1097 424 1097 424 1097 426 1099 423
1096 426 1095 426 394 1131 1093 425 1096 426 1097 425 1096 426 1095 429
1093 427 1094 428 1093 427 1095 427 1095 428 1093 430 1092 431 1091 427
393
=============================================
Received 5234687
=============================================
=============================================
GENERAL
=======
Received 5234687
Bitlength 24
Protocol 1
Delay(pulse length in us) 381
(delay provided from rc-switch)
STATISTICS
==========
Duration of data bits in pulse train : 36537
Data bit duration = 1522 and standard deviation = 4.00
Coefficient of variation of data-bit duration = 0.26 % (should be less than 10%)
Do not use the rest of the information if big coefficient of variation
Long-to-short duration ratio for data bits (rounded) = 3
Sync bit (in multiples of the pulseLength) = 1 29
Proposed protocol for RCswitch
{ 381, { 1, 29 }, { 1, 3 }, { 3, 1 }, false }
STATISTICS OF VARIATION BY LEVELS
=================================
(Differences here are probably artifacts from signal creation or detection)
(This might be completely ignored, but pay attention to them if big differences are present and emission does not work)
number of bits set (in 5234687): 20
longup, longdown, shortup, shortdown
1093, 1132, 394, 427
this might be useful for tweaking emmitting algorithms
=============================================
RAW SIGNAL (us)
===============
first level down
10930
394 1146 1093 427 394 1126 395 1128 1096 425 1096 424 1096 426 1097 425
1097 427 1094 426 394 1130 1094 427 1095 427 1094 429 1092 427 1094 427
1094 429 1092 429 1092 429 1092 430 1091 429 1092 429 1093 430 1095 429
391
=============================================
Any idea why this doesn’t work?
- The LED-strip remote is using the same code for ON/OFF-Switch. My goal is to “catch” the codes sent by the remote with my raspberry in order to “know” the current state of the LED strip. Receiving the code works already and I can fetch the code and display it in BasicUI. One problem is that the code is sent multiple times - in the openhab-log I can see:
2018-06-21 10:36:28.000 [vent.ItemStateChangedEvent] - MQTT_data changed from to 5234687
==> /var/log/openhab2/openhab.log <==
2018-06-21 10:36:28.003 [INFO ] [.eclipse.smarthome.model.script.INFO] - 433MHz signal received [5234687]
==> /var/log/openhab2/events.log <==
2018-06-21 10:36:28.009 [vent.ItemStateChangedEvent] - MQTT_Remote changed from OFF to ON
2018-06-21 10:36:28.017 [vent.ItemStateChangedEvent] - MQTT_data changed from 5234687 to
==> /var/log/openhab2/openhab.log <==
2018-06-21 10:36:28.018 [INFO ] [.eclipse.smarthome.model.script.INFO] - 433MHz signal received []
==> /var/log/openhab2/events.log <==
2018-06-21 10:36:28.199 [vent.ItemStateChangedEvent] - MQTT_data changed from to 5234687
==> /var/log/openhab2/openhab.log <==
2018-06-21 10:36:28.200 [INFO ] [.eclipse.smarthome.model.script.INFO] - 433MHz signal received [5234687]
==> /var/log/openhab2/events.log <==
2018-06-21 10:36:28.212 [vent.ItemStateChangedEvent] - MQTT_Remote changed from ON to OFF
2018-06-21 10:36:28.221 [vent.ItemStateChangedEvent] - MQTT_data changed from 5234687 to
==> /var/log/openhab2/openhab.log <==
2018-06-21 10:36:28.227 [INFO ] [.eclipse.smarthome.model.script.INFO] - 433MHz signal received []
==> /var/log/openhab2/events.log <==
2018-06-21 10:36:28.396 [vent.ItemStateChangedEvent] - MQTT_data changed from to 5234687
==> /var/log/openhab2/openhab.log <==
2018-06-21 10:36:28.400 [INFO ] [.eclipse.smarthome.model.script.INFO] - 433MHz signal received [5234687]
==> /var/log/openhab2/events.log <==
2018-06-21 10:36:28.407 [vent.ItemStateChangedEvent] - MQTT_Remote changed from OFF to ON
==> /var/log/openhab2/openhab.log <==
2018-06-21 10:36:28.414 [INFO ] [.eclipse.smarthome.model.script.INFO] - 433MHz signal received []
My TX-Rule looks like:
rule "433MHz TX"
when
Item MQTT_Remote changed from OFF to ON or
Item MQTT_Remote changed from ON to OFF
then
try {
// Lock transmitter so other executed rules dont't use it at the same time
transmitter.lock()
// Manual reset, somehow it get stuck sometimes.
// This avoids a lock when state of Remote_CodeSend is not updated properly.
Remote_CodeSend.sendCommand(OFF)
Remote_CodeSend_Args.sendCommand("11607809")
logInfo("INFO","433MHz signal send [11607809]")
// Manual trigger transmitter
// If Remote_CodeSend_Args is set to the same value it does not trigger
// when autorun=true, so set autorun=false and use manual trigger to be
// able to trigger one command multiple times.
Remote_CodeSend.sendCommand(ON)
// Wait for the command to complete.
while(Remote_CodeSend.state != OFF){
Thread::sleep(100)
}
// Reset switch signalize command is finished.
triggeringItem.postUpdate(OFF)
}catch(Throwable t) {}
finally {
transmitter.unlock()
}
end
The problem here is, that when receiving the code, my RX-rule is triggering the TX-rule 
rule "433MHz RX"
when
Item MQTT_data changed
then
logInfo("INFO","433MHz signal received [" + MQTT_data.state + "]")
switch MQTT_data.state {
// LED-Steuerung Terrasse ON/OFF=5234687
case "5234687": {
if (MQTT_Remote.state == OFF) {
MQTT_Remote.postUpdate(ON)
} else {
MQTT_Remote.postUpdate(OFF)
}
}
}
if(MQTT_data.state.toString !="") {
MQTT_data.postUpdate("")
}
end
Is there any chance to avoid triggering the TX rule when RX is received (the problem is the switch in the UI - of course I want be able to “control” the LED-strip within the UI too.
Thanks in advance,
Flip
1 Like
it is not really possible to follow your setup, as you only post the rules. So i have to gues what you do or try to do with your items.
- the value in your rule “433MHz TX” is not the value which is transmitted int the log. Either you posted a old/changed rule or something different happens.
- How i remind it
codesendis transmitting the value 10 times. As you resetMQTT_data.postUpdate(""), maybe it is fast enough to register more then 1 time. You can change this behaviour by adding some changes tocodesend.cppand recompile it.
if (pulseLength != 0) mySwitch.setPulseLength(pulseLength);
// Add this line
mySwitch.setRepeatTransmit(1);
mySwitch.enableTransmit(PIN);
mySwitch.send(code, 24);
Just closely follow the examples. 
And 3. received command vs changed and the use of sendCommand and postUpdate.
I use received command which only triggers the rule when the UI was used or a sendCommand to the item was issued. Then I use postUpdate in the rules to change the state of the items but not trigger the rule.
Maybe this helps you.
You need to imagine the control flow as follows.
The LED_Stripe_OnOff is pushed which sets the command and triggers the transmitter Remote_CodeSend.
Then MQTT_data receives data and changes LED_Stripe_OnOff .
But as 433MHz transciever are very bad you will not know if the led is really on, you only know if yyou sended the command or the real remote sended the command.
This is not tested and could contain errors.
Thing exec:command:remote-codesend [
command="/home/pi/src/433Utils/RPi_utils/codesend %2$s",
interval=0,
autorun=false]
Group:Switch:OR(OFF, ON) GledStripe_1
Switch LED_Stripe_OnOff (GledStripe_1) { autoupdate="false" } // prevent updating when UI is triggered
String MQTT_data "MQTT says: [%s]" {mqtt="<[mosquitto:433MHz:state:default]"}
Switch Remote_CodeSend { channel="exec:command:remote-codesend:run" }
String Remote_CodeSend_Args { channel="exec:command:remote-codesend:input" }
String Remote_CodeSend_Out { channel="exec:command:remote-codesend:output" }
import java.util.concurrent.locks.ReentrantLock
val ReentrantLock transmitter = new ReentrantLock
rule "LED Stripe 1"
when
Member of GledStripe_1 received command
then
//logInfo("LED_Stripe", "Member " + triggeringItem.name + " to " + receivedCommand)
try {
// Lock transmitter so other executed rules dont't use it at the same time
transmitter.lock()
// Manual reset, somehow it get stuck sometimes.
// This avoids a lock when state of Remote_CodeSend is not updated properly.
Remote_CodeSend.sendCommand(OFF)
switch triggeringItem.name {
case "LED_Stripe_OnOff" : Remote_CodeSend_Args.sendCommand("5234687")
default : logInfo("LED", "Error in switch!")
}
// Manual trigger transmitter
// If Remote_CodeSend_Args is set to the same value it does not trigger
// when autorun=true, so set autorun=false and use manual trigger to be
// able to trigger one command multiple times.
Remote_CodeSend.sendCommand(ON)
// Wait for the command to complete.
while(Remote_CodeSend.state != OFF){
Thread::sleep(100)
}
//logInfo("LED_Stripe",
// Remote_CodeSend_Out.state.toString.replaceAll("\r|\n"," ") )
}catch(Throwable t) {}
finally {
transmitter.unlock()
}
end
rule "433MHz RX"
when
Item MQTT_data changed
then
switch MQTT_data.state {
case "5234687": if (LED_Stripe_OnOff.state == OFF) {
LED_Stripe_OnOff.postUpdate(ON)
} else {
LED_Stripe_OnOff.postUpdate(OFF)
}
}
if(MQTT_data.state.toString !="") MQTT_data.postUpdate("")
end
Hi Josar,
thanks for your quick reply and sorry I didn’t post my whole configuration. Let me do this now:
My config is like this: I have a QNAP-NAS on which I installed a virtual machine running Debian stretch. There is my openHAB-Installation and the MQTT-broker (mosquitto). The raspi with the 433MHz sender and receiver is in another room nearby a window to receive codes which has been sent by the original remote control and to send codes for the LED-strip.
The reason for the different code in 433MHz_TX.rules is just not to run into the IF in 433MHz_RX.rules:
switch MQTT_data.state {
// LED-Steuerung Terrasse ON/OFF=5234687
case "5234687": {
if (MQTT_Remote.state == OFF) {
MQTT_Remote.postUpdate(ON)
} else {
MQTT_Remote.postUpdate(OFF)
}
}
}
Here are the items/sitemap and things:
test.items
String MQTT_data "MQTT says: [%s]" {mqtt="<[mymosquitto:433MHz:state:default]"}
Switch MQTT_Remote
Switch Remote_CodeSend { channel="exec:command:remote-codesend:run" }
String Remote_CodeSend_Args { channel="exec:command:remote-codesend:input" }
String Remote_CodeSend_Out { channel="exec:command:remote-codesend:output" }
default.sitemap
Frame label="RF-Sensor"
{
Text item=MQTT_data
Switch item=MQTT_Remote
}
exec.things
Thing exec:command:remote-codesend [
command="ssh pi@192.168.2.41 /home/pi/433Utils/RPi_utils/codesend %2$s",
interval=0,
autorun=false]
I run the codesend-command on the raspi via ssh! I also tried to do this as user openhab on my QNAP - this works.
I will change the code in codesend.cpp now and let you now
Thanks again for your help!
Flip
Hello again,
I just did the modification of codesend.cpp:
if (pulseLength != 0) mySwitch.setPulseLength(pulseLength);
mySwitch.setRepeatTransmit(1);
mySwitch.enableTransmit(PIN);
mySwitch.send(code, 24);
return 0;
But when I run codesend now, the sniffer doesn’t detect a code…
Regards,
Flip
What kind of transmitter and receiver are you using. I have TX and RX on different pins as I use to devices. So I receive what I transmitt. I could imagine that a combined transciever connected to one pin does not work, as the pin can not decode while encoding.
Hi Josar,
I do have the same config. 2 seperate modules (RX and TX):
on 2 different pins:
PIN 11: GPIO17 => Data TX
PIN 13: GPIO27 => Data RX
And yes, I do receive what I send.
Regards,
Flip
???
Hi Josar,
after changhing and compiling codesend.cpp with mySwitch.setRepeatTransmit(1), RFSniffer doesn’t detect a code anymore when I send a code via codesend. Before RFSniffer detected everything I sent via codesend.
Regards,
Flip
Just a shoutout to all of you guys installing this binding with the latest openhab release.
I didn’t need to change any users/permissions.
My setup: Latest openhabian on a raspberry.
so what you do is really quite simple:
- Install wiringpi
- Install raspberry-remote
- Navigate to the folder where you installed it and try it with ./send XXXXX X X (X is for your house code)
if they work your good to go to openhab
Install the Exec Binding.
Put:
Thing exec:command:remote-send [
command="/home/openhabian/raspberry-remote/send %2$s",
interval=0,
autorun=true]
My case at least.
Then Make up your items. My example:
Group gFunk
Switch Power_Plug_Socket_1 "Gartenpumpe" (gFunk)
Switch Power_Plug_Socket_2 "Laterne" (gFunk)
Switch Power_Plug_Socket_3 "Flur oben" <light> (gFunk)
Switch Power_Plug_Socket_ALL "Alle Funksteckdosen" (gFunk)
Switch Remote_Send { channel="exec:command:remote-send:run" }
String Remote_Send_Args { channel="exec:command:remote-send:input" }
String Remote_Send_Out { channel="exec:command:remote-send:output" }
And last: Make a rule to switch them on/off:
rule "Single Plug"
when
Item Power_Plug_Socket_1 received command or
Item Power_Plug_Socket_2 received command or
Item Power_Plug_Socket_3 received command
then
logInfo("File", triggeringItem.name + " auf " + receivedCommand)
try {
// lock transmitter so other executed rules don't use it at the same time
transmitter.lock()
val num = triggeringItem.name.toString.split("Power_Plug_Socket_").get(1)
if(receivedCommand == ON){
Remote_Send_Args.sendCommand("11111 " + num +" 1")
}else{
Remote_Send_Args.sendCommand("11111 " + num +" 0")
}
// wait for the command to complete
while(Remote_Send.state != OFF){
Thread::sleep(100)
}
// multiple trigger do not work if there is no break here
// maybe external skript needs some time to properly free resources.
Thread::sleep(400)
logInfo("Power_Plug", Remote_Send_Out.state.toString.replaceAll("\r|\n"," ") )
}catch(Throwable t) {}
finally {
transmitter.unlock()
}
end
And youre done. Actually quite straight forward.
I know that around a your ago when I initially set up openhab it took me ages to fiddle with sudoers and all that user stuff I had no idea of…
1 Like
Dear everybody,
I am facing currently the issue that from time to time my transceiver is not sending commands to my 433 plugs. I then have to restart OH / or the pi. Then it works fine for certain calls of some plugs until nothing is working again. I have a combination of two rules due to the fact that I am having to different types of plugs (one is using remote-send, the other one remote-codeäsend channel). The problem is coming in both cases.
Due to the fact that I am not an Linux or coding specialist I expect that the problem could be in the code (transmitter not unlocks or sth. like that)? Maybe @soesas or @Josar you have an idea?
my rule file based on your valuable comments:
rule "Single Plug"
when
Member of G_All_Plugs received command
// Item of Group Power Plugs received command or
then
logInfo("Power_Plug", "Schalter" + triggeringItem.name + " to " + receivedCommand)
val ReentrantLock transmitter = new ReentrantLock
try {
// Lock transmitter so other executed rules dont't use it at the same time, Concurrent calls of the rule will wait till the resource is free again.
transmitter.lock()
// Get the item which triggered the rule, Split the name and get the second part, the number to set as command.
val num = triggeringItem.name.toString.split("Power_Plug_Socket_").get(1)
// Set the command which should be executed to the output channel, Auto trigger will then execute the Thing.
if(receivedCommand == ON){
Remote_Send_Args.sendCommand("1XXX1 " + num +" 1")
}else{
Remote_Send_Args.sendCommand("1XXX1 " + num +" 0")
}// Wait for the command to complete
while(Remote_Send.state != OFF){
Thread::sleep(100)
}// Mulltiple trigger do not work if there is no break here, maybe external skript needs some time to properly free resources.
Thread::sleep(400)
logInfo("Power_Plug", Remote_Send_Out.state.toString.replaceAll("\r|\n"," ") )
} catch(Throwable t) {}
finally
{ // Free the resource for the next call.
transmitter.unlock()
}
end
rule "Poweroutlet 1"
when
Item Power_Plug_ABC_1 received command
then
if(receivedCommand == ON){
Remote_CodeSend_Args.sendCommand("1XXXXXX6 4")
}else{
Remote_CodeSend_Args.sendCommand("1XXXXXX0 4")
}
// wait for the command to complete
while(Remote_Send.state != ON){
Thread::sleep(500)
}
logInfo("Power_Plug_ABC_1", "Results are: \n" + Remote_CodeSend_Out.state )
end
I am using Exec 2.4.0.
Thank you in advance.