Seeed Human Presence Sensor

[skunkiechris]

Hi @Goose66, I have two of these hooked up, but they are not reporting real time status changes.  They seem to only update on short poll.  Is there something I'm doing wrong? 

Edit: I set the console teleperiod to 10 again, and now I seem to get changes reported every time we hit the 10 second mark.  Is this how it's supposed to work?  I thought a device event should trigger a status change?  

Thanks!

Edited April 15 by skunkiechris

[EWhite]

let me look at whats going on better....

 

Edited April 15 by EWhite

[EWhite]

post #2 of my writeup....

 

  Quote

You now need to go to Tools again, and go to Console.

Down at bottom of screen in the command box type : TelePeriod 10

and hit enter. this sets update time to 10 seconds on MQTT messages.

 

Expand  

you can change this to whatever you want in seconds for reporting...not sure you will ever get "real time" reporting as i would think it would overwhelm the MQTT server with messages...

[skunkiechris]

Right, I wouldn't think that should go too low.  Yes, I did see and set the teleperiod.  I was just under the impression an event would trigger reporting, vs waiting for a time to come around.  So that's (obviously?) not true then?

Thanks!!

  On 4/15/2025 at 1:01 PM, EWhite said:

post #2 of my writeup....

 

you can change this to whatever you want in seconds for reporting...not sure you will ever get "real time" reporting as i would think it would overwhelm the MQTT server with messages...

Expand  

 

[Goose66]

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

[EWhite]

  On 4/15/2025 at 4:53 PM, Goose66 said:

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

Expand  

yes..

 

[EWhite]

  On 4/15/2025 at 3:46 PM, skunkiechris said:

Right, I wouldn't think that should go too low.  Yes, I did see and set the teleperiod.  I was just under the impression an event would trigger reporting, vs waiting for a time to come around.  So that's (obviously?) not true then?

Thanks!!

 

Expand  

I think that since this device uses MQTT you will never get an immediate response.

for me it was not a big deal....i dont need to know the EXACT moment something happened...it just had to be close.

im not sure what other devices are out there and if the offer the same detail you want, along with working along side EISY.

 

[Goose66]

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?

[skunkiechris]

  On 4/15/2025 at 6:31 PM, Goose66 said:

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?

Expand  

The occupancy delays is set to 0 on all of my devices.  @Goose66 Can I send logs?  I have MQTT explorer, just not sure what to send.

[Goose66]

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

[skunkiechris]

  On 4/16/2025 at 3:31 PM, Goose66 said:

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

Expand  

Maybe I'm missing it entirely, I do not see a way to export the data....and there are (presumably) no status update messages as there is no /stat for these devices?

Edited April 17 by skunkiechris

[Goose66]

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/

Edited Friday at 04:47 AM by Goose66

[skunkiechris]

Okay I've posted a bunch of idea and they're all wrong.  I can't figure out how to get the message in for Presence Occupied.  I've tried every way I can think of, I've just been publishing from the console, but nothing changes IoX.

Here are the logs from the TelePeriod:

15:54:40.406 MQT: tasmota/tele/DR_Occupancy/STATE = {"Time":"2025-04-18T15:54:40","Uptime":"2T02:31:13","UptimeSec":181873,"Heap":130,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":4,"Berry":{"HeapUsed":25,"Objects":420},"Wifi":{"AP":1,"SSId":"FCZWH","BSSId":"52:D9:E7:91:42:E2","Channel":6,"Mode":"HT40","RSSI":76,"Signal":-62,"LinkCount":1,"Downtime":"0T00:00:03"}}
15:54:40.418 MQT: tasmota/tele/DR_Occupancy/SENSOR = {"Time":"2025-04-18T15:54:40","HPSensor":{"Human":{"Presence":"Unoccupied","Body Movement Parameter":0,"Activity":"None","Motion":"None"}}}

Based on other examples I've seen, I think it should be something like:
 

publish tasmota/stat/DR_Occupancy/SENSOR {"HPSensor":{"Human":{"Presence":"Occupied"}}}

It creates the following entry in MQTT explorer uinder tasmota/stat/DR_Occupancy/SENSOR

{
  "HPSensor": {
    "Human": {
      "Presence": "Occupied"
    }
  }
}

Here's the SENSOR content for that device:

{
  "Time": "2025-04-18T14:10:27",
  "HPSensor": {
    "Human": {
      "Presence": "Unoccupied",
      "Body Movement Parameter": 0,
      "Activity": "None",
      "Motion": "None"
    }
  }
}

This seems right-ish, but the status in IoX never changes when I manually put occupied in there.  I may be way off base, or just putting it in the wrong place, but this was what I could gather from examples and documentation. I did try putting all parameters in there but it made no difference, still didn't work.

As far as the trigger, I think I need to use status change on GIPO06 or 7? which appear to be the only active options...

Any pointers/help you can give @Goose66 would be appreciated!!

 

  On 4/18/2025 at 4:32 AM, Goose66 said:

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/

Expand  

 

Edited Friday at 02:57 PM by skunkiechris

[Goose66]

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.

[skunkiechris]

1. I did set the TelePeriod to 600 when I was testing to avoid that problem.

2. Tried with the command above, did not get a DON, presence change in the console.

3. Will do so now!

  On 4/18/2025 at 3:40 PM, Goose66 said:

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.

Expand  

 

[skunkiechris]

In case anyone runs into issues with this, the above was correct, however one of my incorrect attempts knocked the plugin listener offline.  So all I had to do was restart the plugin.  

One thing I can't find now, is documentation on what the trigger is that we need...I highly doubt anyone knows this, but I'm just not finding much documentation about the tasmota firmware on this sensor (which would presumably give triggers out).  @EWhite looping you in to see if you have insight on documentation.

Thanks!!

  On 4/18/2025 at 4:22 PM, skunkiechris said:

1. I did set the TelePeriod to 600 when I was testing to avoid that problem.

2. Tried with the command above, did not get a DON, presence change in the console.

3. Will do so now!

 

Expand  

 

[Goose66]

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.

[EWhite]

ESPHome would prolly be WAY better....this tasmota thing was a bandaid to make it work under the "at the time" restraints of EISY and lack of support for ESPHome at the time.

I would gladly change it over ESPHome if it was available. I changed all my RATGD over to the ESPHome side and love the results from it...works way better with less interaction needed "i.e. babysitting the damn things"

[skunkiechris]

HI all,

Thanks for the input.  Since these are set up and working now, I'll stick with Tasmota for the time being.  If anyone else uses these, the rule for making them report real time status for presence is:

ON HPSensor#Human#Presence=Occupied DO publish tasmota/stat/DR_Occupancy/SENSOR {"HPSensor":{"Human":{"Presence":"Occupied"}}} ENDON

Obviously replace DR_Occupancy with your own sensor name, but it's working perfectly.  Thanks to @Goose66 for getting me here!

Edit: Weirdly on all 5 of my devices, the unoccupied rule fires continuously, with no occupancy between, no idea why - maybe will look for help in the seeed forums.  However, unoccupied isn't nearly as important, so I set the TelePeriod to 30 and turned the unoccupied rule off, so I'll get immediate occupied, and up to a 30 second delay for unoccupied - but since the lights wouldn't be turned off immediately anyway, not so important really.  Granted I'd still like to fix it out of principle, however, not sure that will be possible.  Seems like the unit is returning unoccupied constantly.  I tried blocking one of them and it still constantly reports unoccupied.  Shrug.

Edit2: AHhhhh, Goose was right, these sensors report status constantly, so the rule keeps firing. Going have each rule disable the other one until it's no longer true. Solved!

Edit3: Turns out Berry scripting has a built in "only run once on a status change" function, so all good to go even simpler!

Edited Saturday at 09:51 PM by skunkiechris

[Goose66]

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.

[skunkiechris]

Assuming you mean try that literally? It did not work:

20:52:34.393 CMD: publish tasmota/stat/%topic%/STATE
20:52:34.409 MQT: tasmota/stat/%topic%/STATE = 

and it published nothing in explorer.

  If I'm being an idiot and that is not what you meant, feel free to chastise me. 😛 

  On 4/21/2025 at 3:15 PM, Goose66 said:

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.

Expand  

 

[Goose66]

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.