For devices that do not confirm their state like these switches, you are relying on an assumption that the device is in the state last recorded in HASS.
The best way to improve reliability is to look for devices with separate on / off buttons so you know the intention is to turn off the device (for example). Not a guarantee that it worked but at lest you know your intention.
Single buttons that toggle can get out of sync very easily!
@1technophile They are 220V powered, I’m from Europe and here we are using only 2 wires for the lamp switches, so there is only 1 live wire and one wire that is going to the lamp itself, there is no GND
Sorry @ReneTode I don’t have a spare one to open it completely…
with only 1 live wire, how is it 220v powered?
if the ligt is out, there is no power to the switch, but it still needs power to put the switch back on.
so, some kind of powerstorage must be inside the switch.
Do they only send the signal on the event, or do they periodically send the current state? One thing I wasn’t really considering, is if HA gets out of sync when I restart it, or upgrade it or something.
they only send signal on the event. To keep track the state, I created an automation to publish an MQTT topic with retain option when I receive the original topic from the gateway. After that I only focus on the newly created topic for automation and other stuff.
Can you make the gateway to publish only a single code when the sensor is triggered? The reason why is some of the sensors send out 10 to 20 same codes in a single burst. This will make the automation in my HA to go crazy and sometimes crashes it. For now, I overcome this by using automation.turn_off and then delay for few seconds before automation.turn_on. For example…
If you look at some of the sketches for his NodeMCU based gateways, he has some deduping logic. I added some of it in my arduino based version. I am, however, considering moving to a NodeMCU because it has more SRAM that can be used to dedupe more 433 device events.
Look at the isAduplicate function, and supporting functions/variables.
One thing I did notice, on the arduino version at least, if I have 2 devices send at the same time, I get nothing. On rare occasions, I get payload that doesn’t match either of them. I’m not sure if it is something in the RCSwitch, or just a limit of the protocol.
thanks. are you referring to the time_avoid_duplicate variable? I think mine was based on older version and I don’t think it has that option. Anyway, I will try it out soon.
The block of if (mySwitch.available()) inside the loop. It has calls to isAduplicate and storeValue.
The functions getMin, storeValue, and isAduplicate.
The #define time_avoid_duplicate 3000
The variable long ReceivedRF[10][2]
Basically it keeps track of the 10 most recent events (based on the number received from the 433 receiver) and dedupes based on that. The arduino uno version is very memory limited, 2k of SRAM, so you wouldn’t really be able to go more than that.
Hopefully you don’t have more than 10 devices transmitting duplicates during the same 3 second interval.
This evening, or maybe tomorrow evening, I can probably, if @1technophile doesn’t beat me to it, and doesn’t mind, add those functions to the original Arduino Uno version. Are you using that version or the first ESP8266 version?
yes. i have updated the sketch to the latest version and I have changed the time_avoid_duplicate value to 1 millisecond. When the sensor trigger, it still publishes multiple same code to the broker.
I think you need to leave the time_avoid_duplicate high, like 2000 or 3000. I noticed for the door sensors from aliexpress, they keep transmitting as long as you see the light. That is, they push the signal multiple times over 2 or 3 seconds.
The dedupe logic stores the first time it see the signal and then the next time, and the next time, and the next time. The time between the first time and the last time is what the time_avoid_duplicate needs to be.
1 millisecond isn’t near enough. Try between 250 and 3000.