Hacking Arlec's 'Smart' sensor light
- Comments:
- here.
Quite some time ago, I purchased one of the Arlec Smart Security Lights from Bunnings. The big draw for me was that these devices have an ESP8266, and run a Tuya firmware, which can be trivially flashed without opening up the unit.
In this case, though, the device was not really that capable. Whilst there is a PIR sensor (and an LDR for tuning if the light should turn on yet or not), the status of the PIR is not exposed at all. Instead, the firmware allows toggling between three states: “ON”, “OFF”, and “SENSOR”.
That’s not actually that useful. For one, it makes using it in conjunction with a physical switch really inconvenient. The behaviour I would prefer is:
- Light ON/OFF state can be toggled by network request.
- Light ON/OFF state can be toggled by physical switch. It must not matter which state the switch is in, toggling it must toggle the light.
- PIR ON turns ON the light.
- PIR OFF turns OFF the light, but only if it was turned ON by PIR.
As the last point indicates, the only time the PIR turning off should turn the light off is if the light was turned on by the PIR. That is, either physical switch actuation or a network request should turn the light into manual override ON.
There is no manual override OFF.
Most of this was already present in a firmware I wrote for adding a PIR to a light strip. However, the ability to also toggle the state using a physical switch is important to me: not in the least because there is a switch inside the door where I want to mount this, and I’m very likely to accidentally turn it on when I go outside: it’s also a much better solution to a manual override than just having to use HomeKit. I’ll possibly add that feature back into the aforementioned project.
Like all of the other Grid Connect hardware I’ve used so far, it was easy to flash using tuya convert. But I did run into a bunch of problems from that point onwards. The base contains the ESP8266, one of the TYWE2S units, and it’s possible to see without opening up the sensor unit that this has three GPIO pins connected: GPIO4, GPIO5 and GPIO12.
With a custom firmware, it was possible to see that GPIO5 is connected to the green LED near the PIR sensor, but the other two appear to be connected to another IC on the PCB. I thought perhaps this could be accessed using the TuyaMCU protocol, but had no luck.
As it turns out, I’d prefer not to have to use that. There are two more wires, it would be great if I could connect one of them to the relay, and the other to the PIR.
Indeed, with limited rewiring (I did have to cut some tracks and run wires elsewhere), I was able to connect GPIO12 to the point on the PCB that the output from the other IC that triggered the relay, and GPIO4 to the input of the IC that was sensing the PIR output.
I also ran an extra pair of wires from GPIO14 and GND, to use to connect to the physical switch. These will only transmit low voltage.
Unfortunately, I forgot to take photos before putting it all back together and having it mounted on the wall.
Then we just need the firmware:
esphome:
name: $device_name
platform: ESP8266
board: esp01_1m
globals:
- id: manual_override
type: bool
restore_value: no
initial_value: 'false'
- id: mqtt_triggered
type: bool
restore_value: no
initial_value: 'false'
sensor:
- platform: wifi_signal
name: "WiFi signal sensor"
update_interval: 60s
binary_sensor:
- platform: gpio
pin: GPIO4
id: pir
device_class: motion
filters:
- delayed_off: 15s
on_press:
- light.turn_on: green_led
- mqtt.publish:
topic: HomeKit/${device_name}/MotionSensor/MotionDetected
payload: "1"
- switch.turn_on: relay
on_release:
- light.turn_off: green_led
- mqtt.publish:
topic: HomeKit/${device_name}/MotionSensor/MotionDetected
payload: "0"
- if:
condition:
lambda: 'return id(manual_override);'
then:
logger.log: "Manual override prevents auto off."
else:
switch.turn_off: relay
- platform: gpio
pin:
number: GPIO14
mode: INPUT_PULLUP
name: "Toggle switch"
filters:
- delayed_on_off: 100ms
on_state:
- switch.toggle: relay
- globals.set:
id: manual_override
value: !lambda "return id(relay).state;"
ota:
logger:
output:
- platform: esp8266_pwm
id: gpio5
pin:
number: GPIO5
inverted: False
switch:
- platform: gpio
id: relay
pin:
number: GPIO12
# inverted: True
# mode: INPUT_PULLDOWN_16
on_turn_on:
- if:
condition:
lambda: 'return id(mqtt_triggered);'
then:
logger.log: "No MQTT message sent"
else:
mqtt.publish:
topic: HomeKit/${device_name}/Lightbulb/On
retain: ON
payload: "1"
on_turn_off:
- if:
condition:
lambda: 'return id(mqtt_triggered);'
then:
logger.log: "No MQTT message sent"
else:
mqtt.publish:
topic: HomeKit/${device_name}/Lightbulb/On
retain: ON
payload: "0"
light:
- platform: monochromatic
id: green_led
output: gpio5
restore_mode: ALWAYS_OFF
default_transition_length: 100ms
mqtt:
broker: "mqtt.lan"
discovery: false
topic_prefix: esphome/${device_name}
on_message:
- topic: HomeKit/${device_name}/Lightbulb/On
payload: "1"
then:
- globals.set:
id: mqtt_triggered
value: 'true'
- switch.turn_on: relay
- globals.set:
id: mqtt_triggered
value: 'false'
- globals.set:
id: manual_override
value: !lambda "return !id(pir).state;"
- topic: HomeKit/${device_name}/Lightbulb/On
payload: "0"
then:
- globals.set:
id: mqtt_triggered
value: 'true'
- switch.turn_off: relay
- globals.set:
id: manual_override
value: 'false'
- globals.set:
id: mqtt_triggered
value: 'false'
I’ve also implemented a filter on sending the state to MQTT: basically, we don’t want to send a message to MQTT if we received the same message. There is a race condition that can occur where this results in fast toggling of the relay as each toggle sends a message, but then receives a message with the alternate state. I’ve had this on my Sonoff Mini firmware too.
