Goose66

What plugin?

I can't speak for MyQ doors, but it is very stable for my dry-contact Genie doors. Never had an accidental opening or anything like that.

No that’s what I meant. At least on the Martin Jerry Tasmota devices, if you use %topic% in a rule, it is replaced with whatever is specified for “Topic” in the MQTT configuration.

Does "tasmota/stat/%topic%/STATE" work instead of having the actual name of the device in there? If that works, and you post back the exact rules that you used, I can make the Tasmota Plugin configure the HPSensor devices with those rules upon discovery. I need to roll out a new version to fix the failure on bad MQTT data that we found while debugging this.

The Tasmota “drivers” for the device are here: https://github.com/blakadder/berry-drivers I’m probably out of my depth here, but looking at the Berry code, it seems the driver is updating the Tasmota core OS with the state values every 50ms. You could probably learn Berry and fork this driver code and add mqtt publishing on value changes. Another possibility: if someone wants to send me one of these, I would consider writing a plugin for the ESPHome firmware. Tasmota is just not a great device OS. That’s why I never expanded the device support in the Tasmota plugin. The ESPHome firmware (which appears to be available) may offer better features for this particular device. I know it offers better programming interfaces.

From a quick look at the code, this should be working. As I said, the code handles tele/ and stat/ messages in exactly the same way, so simply substituting "stat" for "tele" should work. Just FYI, this is not the case for other Tasmota devices -- the formats of the stat/ and tele/ messages are very different. I assume I implemented the HP Sensor code this way because it was all the information I had at the time (I don't own any of these devices and was just working off @EWhite's logs/input). All that said, there are several things to try in debugging this: 1. It could be a simple matter of timing. Since the teleperiod is set to the minimum of 10 seconds, the device itself may be switching the Presence (ST) driver value back to 'Unoccupied' every 10 seconds and you just aren't seeing IoX update to 'Occupied' because of this timing. So first try setting the teleperiod to a higher value, e.g. 30 seconds, through the device's Tasmota console. 2. When the plugin updates the Presence (ST) driver value from 'Unoccupied' to 'Occupied' it also sends a DON command. And it sends a DOF command when vice versa. So even if the resetting back to 'Unoccupied' is happening every 10 seconds by the tele/ messages, you should still be getting these commands for the device. Try writing an IoX program with " 'DR_Occupancy' is switched On" conditions to see if you can detect the changes. 3. Turning on Debug level for the plugin logging and then trying a few times and DMing a plugin log file (not PG3x log) to me would be the logical next step.

If you can write rules to generate state messages on state changes, the plugin should respond to them. As a starting place, look here: https://tasmota.github.io/docs/Rules/#conditional-rules I can provide specifics as to what the stat messages should look like, but for the most part should just be the tele messages with tele/ replaced with stat/

I believe MQTT Explorer can export logs of messages by topic. There should be stat/<device id> and tele/<device id> topics for each device

The teleperiod should be the periodic telemetry messaging for all tasmota devices, right? In other words, the periodic updates in state sent to the Telemetry "tele/" subtopic. But shouldn't the device send state changes to the State "stat/" subtopic as well when state changes? For example, with switches, you get telemetry messages every 90 seconds or so, but you get state messages instantly. Perhaps we need another MQTT Explorer log output watching one of these things to inventory the messages. And if the device doesn't send state messages on state change by default, it seems like it would be easy to set a Tasmota Rule to send a state message upon state change for each state you want reported right away. Also, there appears to be an "Occupancy Delay" parameter that can be set through the plugin (via Admin Console). What is that set to? Is it possible that is where the 10 second delay is coming from?

Just to be clear, this is a problem with the sensor device, not the Tasmota plugin, I assume.

Right. That’s exactly what it was. I also have that USB interface board for loading the flash module. I didn’t remember all the details.

There’s an SSD (not SD card) on the board. Don’t remember the actual interface protocol(s). NVMe? PCIe? eSATA?

Sounds like an SSD card problem. Hope not, but I went through something similar. IIRC, UD had to send me a new module.

Manually yes, but if I went to the device in UD Mobile or Admin Console and turned it on, then the keypad light wouldn’t turn on. And if the device is in other scenes and is turned on or off via those scenes, then the keypad light wouldn’t be updated. The only way to keep them in sync is with a key state update program.

Problem with Techman’s approach is that if something ever turns the device on or off directly, e.g. a user in UD mobile, or if it is also in other scenes, the keypad light won’t track with the device state. By having separate programs that update the key light state, they should stay in sync.