Send multiple commands to 433 MHz poweroutlets

Setup, Configuration and Use Scripts & Rules
1

After sending a command to the poweroutlets, a second command is not sent.

I am sending a command (exec) to change the state of 433 MHz poweroutlets. And it works great. However, openhab can not know the state of the poweroutlets at any time.
On the one hand they can not answer, if they received the 433 MHz signal. On the other hand openhab can never know, if I sent another signal with a simple 433 MHz remote control.

If I send the command ON to the poweroutlets via openhab, switch them off via remote and want to switch them on again via openhab, they will not be turned ON at the second time. I guess, openhab somehow assumes, that the poweroutlets are still ON.

openhabian@openhabian:~ $ cat /etc/openhab/things/poweroutlets.things

Thing exec:command:poweroutletA-control [ command="/home/openhabian/scripts/call_rpi_433.sh A %2$s", interval=0, autorun=true ]
Thing exec:command:poweroutletB-control [ command="/home/openhabian/scripts/call_rpi_433.sh B %2$s", interval=0, autorun=true ]
Thing exec:command:poweroutletC-control [ command="/home/openhabian/scripts/call_rpi_433.sh C %2$s", interval=0, autorun=true ]
Thing exec:command:poweroutletD-control [ command="/home/openhabian/scripts/call_rpi_433.sh D %2$s", interval=0, autorun=true ]

openhabian@openhabian:~ $ cat /etc/openhab/items/poweroutlets.items
Group grp_poweroutlets "Funksteckdosen Wohnzimmer" <poweroutlet>
String poweroutletASwitch "Funksteckdosen A Kinderzimmer" <poweroutlet>  [ "Switchable" ] { channel="exec:command:poweroutletA-control:input", autoupdate="true" }
String poweroutletBSwitch "Funksteckdosen B Wohnzimmer" <poweroutlet> (grp_poweroutlets) [ "Switchable" ] { channel="exec:command:poweroutletB-control:input", autoupdate="true" }
String poweroutletCSwitch "Funksteckdosen C Schlafzimmer" <poweroutlet>  [ "Switchable" ] { channel="exec:command:poweroutletC-control:input", autoupdate="true" }
String poweroutletDSwitch "Funksteckdosen D Flur" <poweroutlet>  [ "Switchable" ] { channel="exec:command:poweroutletD-control:input", autoupdate="true" }

triggers:
  - id: "1"
    configuration:
      thingUID: deconz:switch:00212E069C7B:0017880108f2559802fc00
      event: "2000"
      channelUID: deconz:switch:00212E069C7B:0017880108f2559802fc00:buttonevent
    type: core.ChannelEventTrigger
conditions: []
actions:
  - inputs: {}
    id: "2"
    configuration:
      itemName: grp_poweroutlets
      command: ON
    type: core.ItemCommandAction

2021-03-31 00:06:32.757 [INFO ] [openhab.event.ChannelTriggeredEvent ] - deconz:switch:00212E069C7B:0017880108f2559802fc00:buttonevent triggered 3000

2021-03-31 00:06:32.759 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'grp_poweroutlets' received command OFF

2021-03-31 00:06:32.762 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'poweroutletBSwitch' received command OFF

2021-03-31 00:06:32.778 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'poweroutletBSwitch' changed from ON to OFF

2021-03-31 00:06:32.810 [INFO ] [openhab.event.ChannelTriggeredEvent ] - deconz:switch:00212E069C7B:0017880108f2559802fc00:buttonevent triggered 3002

2021-03-31 00:06:32.902 [INFO ] [openhab.event.ChannelTriggeredEvent ] - deconz:switch:00212E069C7B:0017880108f2559802fc00:buttonevent triggered 3000

2021-03-31 00:06:32.905 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'grp_poweroutlets' received command OFF

2021-03-31 00:06:32.910 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'poweroutletBSwitch' received command OFF

2021-03-31 00:06:32.991 [INFO ] [openhab.event.ChannelTriggeredEvent ] - deconz:switch:00212E069C7B:0017880108f2559802fc00:buttonevent triggered 3002

2021-03-31 00:06:40.221 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'BewegungsmelderFlurPrasenzCentraLite_LastUpdated' changed from 2021-03-31T00:06:13.130+0200 to 2021-03-31T00:06:40.209+0200

2021-03-31 00:06:42.643 [INFO ] [openhab.event.ChannelTriggeredEvent ] - deconz:switch:00212E069C7B:0017880108f2559802fc00:buttonevent triggered 2000

2021-03-31 00:06:42.646 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'grp_poweroutlets' received command ON

2021-03-31 00:06:42.649 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'poweroutletBSwitch' received command ON

2021-03-31 00:06:42.660 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'poweroutletBSwitch' changed from OFF to ON

2021-03-31 00:06:42.770 [INFO ] [openhab.event.ChannelTriggeredEvent ] - deconz:switch:00212E069C7B:0017880108f2559802fc00:buttonevent triggered 2002

In the log I can see, that the rule is fired. But openhab decides, that it does not actualy have to execute the command. The script is not called, unless it officially received an OFF command before.

How can I convince openhab to always execute the command?

  • Platform information:

    • Hardware: Raspberry Pi 4

    • OS: Linux openhabian 5.10.11-v7l+ #1399 SMP Thu Jan 28 12:09:48 GMT 2021 armv7l

    • Java Runtime Environment: openjdk 11.0.10 2021-01-19 LTS
      OpenJDK Runtime Environment Zulu11.45+27-CA (build 11.0.10+9-LTS)
      OpenJDK Client VM Zulu11.45+27-CA (build 11.0.10+9-LTS, mixed mode)

    • openHAB version: 3.0.1 - Release Build

2

The actual script in case someone is interested:

openhabian@openhabian:~ $ cat scripts/call_rpi_433.sh
# Welcher Schalter (A, B, C oder D) soll betätigt werden?
# Der Schalter kann als Zahl übergeben werden, und wird dann direkt übernommen, oder als Buchstabe.
# TODO: Hier sollte die Syntax stärker forciert werden. Die Eingabe muss geprüft werden!
echo "Starte 433 mit folgendem input:" >> /home/openhabian/scripts/433.log
echo "$1 $2 $3" >> /home/openhabian/scripts/433.log

if [ -z $1 ]
then
    echo "Parameter 1 darf nicht leer sein.";
    exit 1;
fi
if [ $1 = "A" ] || [ $1 = "a" ] || [ $1 = 1 ]
then
    schalter=1;
elif [ $1 = "B" ] || [ $1 = "b" ] || [ $1 = 2 ]
then
    schalter=2;
elif [ $1 = "C" ] || [ $1 = "c" ] || [ $1 = 3 ]
then
    schalter=3;
elif [ $1 = "D" ] || [ $1 = "d" ] || [ $1 = 4 ]
then
    schalter=4;
else
    echo "Parameter 1 muss eine Steckdose von A-D sein.";
    exit 1;
fi

# Soll eingeschaltet werden, oder aus? Welcher neue Status soll erreicht werden?
if [ $2 = "ON" ] || [ $2 = "on" ] || [ $2 = 1 ]
then
        status=1;
else
        status=0;
fi
echo Sende den Status $status an den Schalter $schalter
date >> /home/openhabian/scripts/433.log
echo Sende den Status $status an den Schalter $schalter >> /home/openhabian/scripts/433.log
ssh pi@raspberrypi.local /home/pi/433Utils/RPi_utils/send 01111 $schalter $status
3

Hi Bruno,

why not use something like OpenMQTTGateway to control your 433 power sockets? If you use a gateway which has 433 sender AND receiver it will also recognise when you use your remote control, and update openHAB via MQTT, so that it always has the correct state.

If you already use MQTT for any other devices this is an easy addition

I’m using this for all my 15 433 power sockets and it works very reliably.

Also, just wondering here. Which interface - possibly app - are you using to control openHAB. The web interface should send the command again, even if it is already in the current state, but the iOS app for example doesn’t resend any commands, if a state is already in the current position and it is a segmented control.

All the best.

4

I think you’ll find in most of the UI’s that a simple switch type widget cannot be clicked for ‘on’ while it is already displaying ‘on’. There’s no other other obstruction to commanding ON as often as you like.
You could disable autoupdate on the Item so that its state does not reflect the last command sent
or
I think using a pushbutton style UI display of a switch allows to click on buttons regardless of displayed state.

5

The problem is in the Exec binding’s input Channel. The Item’s state must change for it to trigger the script to run. So your options are:

  • Use a Rule with the executeCommandLine Action
  • Use expire to update the Input Channel Item to NULL a second after it changes to ON or OFF. I don’t think it will trigger the script to run but if it does, modify the script to ignore “NULL” as an argument.
  • Separate the ON and OFF commands into separate Things which means they will be controlled by separate Items which will require proxy Items and rules.
6

Using expire did not help.

I found some information in the docs:
“Note that sending the same command a second time will not trigger execution.”

I will try to send a NULL command after the ON and OFF commands. Perhaps that helps.