Thanks for the fast response! It will now start compiling but then aborts with error 1 after this:
/config/esphome/occupancy.yaml:391:14: error: 'uart_target_output_$shortname' was not declared in this scope
391 | if (id(uart_target_output_$shortname).state && line.substr(0, 6) == "$JYRPO")```
Need some help, the next update is a stretch project for me. I am looking for a small number of testers who are comfortable making breaking changes, potential crashes, and can perform direct serial re-flash if needed.
led/distance/latency/sensitivity state queries from the MCU function as expected
** these occur on_boot, on_value, and when factory_reset_sensor_config are used
Other changes include:
reduced unneeded switches
target tracking is now default behavior
Caveats of my first custom component:
hard-coded entity names in the .h means you cannot change any id
Quite pleased with the way it’s turned out, my own version of an FP1!
Like others I used a D1 mini as my base. I also included a BH1750 lux sensor so I can automate my lights based on ambient light levels - the body lets in enough light for it to take useful measurements.
One slight issue is that it currently will pick up movement in the hallway through the wall you can see to the right of the device in the picture. Dialling down sensitivity unfortunately makes it less useful at picking up distant motion in the room itself. Any ideas on how to prevent it from looking into the hallway?
@crlogic - I have made some tweaks to your code to better utilise substitutions so that if someone wants to set up more than one of these then all the buttons/sensors/switches are easier to differentiate in HA. Also some minor tweaks to units of measurement:
Have you noticed device crashing when target tracking is on? I need to test further but seem to be finding that my setup went through a number of unexpected reboots when both target tracking and UART output were on whilst I was debugging range and sensitivity
I would caution against changing id: as it will be more important in upcoming revisions. name: is fine and can be changed to taste. I will be sure to better highlight this in the future.
Target tracking is definitely chattier and with full debug logging that can occur. I will add an uptime sensor in order to better track this metric moving forward. Especially as I have no ESP8266’s.
The version that defaults to target tracking ON has not been posted. And will not be posted without wider testing. I have noticed that I cannot use longer USB extension cords with target tracking. I just assumed the added power draw + my 16’ cord was pushing it (because with a shorter cable it is ok)
Noted, I’ll keep an eye out for the next version and switch my ids back!
Sensitivity != distance
I know, trouble is that I need higher sensitivity to pick up micro motion at the other end of my living room. And the detections I’ve had in that particular area in my hallway have had pretty good SNRs too (up to 2.0). I’ll have to keep finessing I guess! Will probably have to be longer interval and lower sensitivity…
I have noticed that I cannot use longer USB extension cords with target tracking
I hadn’t considered that at all! I have got mine hooked up with quite a long cable. It’s not an issue for me because I can only see myself using target tracking for initial setup (for now at least) so I don’t need it to be stable long-term.
Ideally we have it enabled without impact to stability across difference devices and implementations. I will be sure to keep the tracking on/off switch otherwise since that really isn’t the key feature being worked. It is the led/distance/latency/sensor_on/off state between the MCU & ESP that I am aiming to better keep in sync.
Since distance is going to be the most powerful tuning mechanism. If you can find a suitable sensor placement location that does not overlap livingroom and hallway distance, that would be best. That way you can max out the sensitivity within the configured distance with less worry about hallway motion. The target tracking is very useful here to understand what distance numbers the sensor is seeing.
@crlogic I was in the process of spinning up a repo on GitHub to create a custom component based on the progress you’ve made but would prefer not to duplicate efforts. I’d be happy to help out with your project. Is there somewhere we can collaborate on the code?
I have been doing additional checks on this topic and noticed that leaving the web_server page open in Chrome triggered a watchdog reset. The odd time I would see an rx_buf error but didn’t catch all of it.
When I do not leave a browser sitting on the ESP web_server things run well (top and bottom entries below). All restarted manually at roughly the same time.
Middle sensor below had page left open and it would run 3-10 min.