Events missed with default timeouts

[shaw-iot]

I'm using this with MIHO033 door sensors on a Pi2. With the default 5000ms timeout it seems to miss events, eg. the closing event if a door is opened and closed in a short time period. Lowering the timeout to 500ms seems to make it more reliable. However, I can't really tell if the root cause of this is because of the sleep in the code (can the buffer fill up and overrun?) or just a radio reception issue. I'm using the default coil antenna on the ener314-rt module.

[shaw-iot]

Playing around with the code, changing the sleep in openThings.c seems to have made it more responsive to events from the door sensors. 50ms seems to work OK and the CPU is <1% for the node task,

[Achronite]

I guess you must be sending 2 messages from the door sensor within the default 5 seconds (5000000 microseconds), hence the 2nd one being 'lost' as the Rx buffer on the board is already full. I did, like you, expect that the buffer could take more than 1 message before being full, but I've NEVER seen this happen in all of my testing.

I would be happier changing to 500ms rather than 50ms, was there something wrong when you tried 500ms?

[shaw-iot]

I've got it linked with Home Assistant and I found with 50ms the door status changed almost immediately on the web GUI. With a longer sleep it lagged a bit more. I've got the energy monitor and that seems to transmit every few seconds so I would imagine in a 500ms time period there's a high probability of two messages occurring. 500ms did work much better than 5000ms, but I found if I opened and door enough times events would eventually get missed. Is the sleep time to keep the CPU usage low, or does it affect the radio? Also, should the sleep time be limited by the time remaining before the timeout configured in Node Red device? e.g. if the device timeout is set to 500ms and 100ms has already elapsed since the start time, the max sleep time would be 400ms?

[Achronite]

It is just to reduce CPU, the radio stays in receive mode all of the time (unless of course you are sending commands!).

I know it works OK with 25ms sleep, as this is what I need to use to send commands to eTRV devices (these have a very small Rx window after transmit, so I need to be quick!).

How did you get it working with HA? Is it using the built-in node-red, as I couldn't get that to work as the (docker) container did not seem to have access to GPIO. Or are you running node-red outside of HA?

https://community.home-assistant.io/t/accessing-gpio-spi-from-custom-node-red-node-node-red-contrib-energenie-ener314rt/170002

[shaw-iot]

I've only been setting this up over the past week so it's not fully worked out. However, this library is a great way to use the ener314-rt module. For the sensors I publish the data to the MQTT broker that's built into HA which runs on a separate Pi4. Node Red is running on a Pi2 with a standard Raspbian install.

In Node Red I form a topic using a function node between the ener314-rt and MQTT nodes. I need to add error checking for null values and other failure conditions, but it seems to work OK for now. For the door sensors (type 13) I wanted the state to persist over a restart.

msg.topic = "energenie/" + msg.payload.productId + "/" + msg.payload.deviceId + "/stat";
if (msg.payload.productId == "13") {
    msg.retain = true;
}
return msg;

On the HA side I've got entries like these in configuration.yaml:

sensor:
  - platform: mqtt
    name: "Incoming Power"
    state_topic: "energenie/5/6409/stat"
    unit_of_measurement: W
    device_class: power
    value_template: "{{ value_json.APPARENT_POWER }}"

binary_sensor:

  - platform: mqtt
    name: "Door"
    payload_on: "1"
    payload_off: "0"
    state_topic: "energenie/13/7318/stat"
    device_class: door
    value_template: "{{ value_json.DOOR_SENSOR }}"

[Achronite]

I've released v0.4.0, you should be able to update using the palette in node-red. Please let me know if this fixes your issues.