-
-
Notifications
You must be signed in to change notification settings - Fork 3.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update PIR Switch Usermod #2724
Conversation
Occupancy is not a function of PIR (motion) sensor. |
Just so I'm clear for future...is the objection to the occupancy sensor the fact that it would prospectively be cluttering up an existing Usermod or is it more of a logical arguement that the motion sensor doesn't sense occupancy, it only senses motion? My rationale for wanting the device to make the decision on occupancy rather than Home Assistant was that, at least when I last worked on the HA side of writing an automation, I don't think you could mark zones as occupied, but it sounds like that may be something that's since been updated, so I'll take a look at that. I can certainly make a reduced version that just does the HA Discovery to expose the motion state. That should be a fairly minimal change. I'll leave this PR open, if that's okay and try and get it done in the next day or so. |
Okay...I've reverted my original commit and submitted a new one with only the HA Discovery elements. Does that look more suitable? |
Minor optimizations
Shorten `Reserved` to `RSVD`
Remove Wire initialisation from RTC. Peek fix.
-new methods: getType(), isInitailized(), postProcessSample() - allow users to compile for RIGHT audio channel (-D I2S_USE_RIGHT_CHANNEL) - better handling in case audio input driver failed to initialize - removed some unneeded code and unneeded parameters
save one KB (4*256 bytes) by not storing the "upper half" of FFT results. Only the lower half has interesting results.
Scrolling text improvement. LED settings bugfix. Audioreactive disabled by default.
- smoothing FFTResult (don't have a matrix to test) - UDP sound sync improvements - some bugfixes from SR WLED - button.cpp: avoid starvation: strip.isUpdating() can be true for a long time. work in progress - still needs testing!!
support the case when only attackTime XOR decayTime is defined
improved ADCsample processing, including replacement of "rogue" samples from other channels (this happens at least once in 5 seconds !!). It compiles, don't ship it yet - needs more testing.
* Release of WLED v0.13.3 * Fixed a type in the file name (Aircoookie#2781) * Fixed the dependency (Aircoookie#2782) * Usermod Wordclock update to use an alternatve wiring pattern (Aircoookie#2757) * Update * update readme file * readme update * Update readme.md * Update readme.md * Update readme.md * Update readme.md * Update platformio.ini * Add number of UDP retries Add a configurable number of retries to the UDP WLED sync function. * Add migration from old eeprom settings * Revert some accidental carry overs * Correct issues found in pull request Change default number of retries Fix migration from old settings * Make the minimum number of retries 0 * Import notify twice setting Co-authored-by: cschwinne <dev.aircoookie@gmail.com> Co-authored-by: Soren Singh Dary <67230851+sorensd@users.noreply.github.com> Co-authored-by: Patrick <40436536+paeppi88@users.noreply.github.com>
Merge 0.14 to main
* Implent publishing DHT data to MQTT broker * Fix naming and add description
Co-authored-by: Christian Schwinne <dev.aircoookie@gmail.com>
* implement analog clock as a usermod * fix some bugs, use toki for time measurement, implement fading seconds * added timezone handling to analog clock * fixed looping second pointer, lower refresh rate * removed mqtt debug code * implement seconds effect choice * adapt to 0_14 branch Co-authored-by: Christian Schwinne <dev.aircoookie@gmail.com>
Co-authored-by: Christian Schwinne <dev.aircoookie@gmail.com>
Removed longPressMacro call Fix debug calls Fix typos
* Starting on Ping Pong Clock Usermod, still having to check the led indices and test the stuff out of it * Adding some attributes to be configured, Added platformio_override * Fixed LED Numbering, Changed Color to RGB to Work with Settings * Removing LED Positions from Config * Some documenting * Removed example comments to make ping pong clock mod more readable Co-authored-by: Schmailzl, Sebastian <sebastian.schmailzl@wk-it.com> Co-authored-by: Christian Schwinne <dev.aircoookie@gmail.com> Co-authored-by: Christian Schwinne <cschwinne@gmail.com>
* Add ESP32_DATA_IDLE_HIGH to enable data pin to go HIGH when relay is off * forgot to remove Serial.print for ESP32_DATA_IDLE_HIGH * forgot another ifdef preventing compilation on non-esp32 boards * Extra checks that the bus is actually an RMT bus Could still blow on new ESP32 variants, but now in a mergable state. Co-authored-by: Christian Schwinne <cschwinne@gmail.com>
Co-authored-by: Christian Schwinne <dev.aircoookie@gmail.com>
* BH1750 upgrades Moved the definitions into the main usermods_list.cpp instead of having a section to copy across. Added Home Assistant Discovery topic for light sensor. This is toggleable from the usermod menu. * Configure pin, other enhancements, readme Implemented pin manager Made pins configurable at runtime Improved info screen outputs Added F() around strings Updated readme * Resolve conflict * Merge branch 'main' * Missing comma Co-authored-by: Christian Schwinne <dev.aircoookie@gmail.com> Co-authored-by: Christian Schwinne <cschwinne@gmail.com>
…TH-POE Un-F() a string that already exists in RAM
support decoding of sound sync data from SR version > 0.13.0
* Create usermod_word_clock_matrix.h Tried using the old usermod on the new build, found out a lot has changed since then. My best attempt to update it. Still needs some help, but it is working. I would like to preconfigure some of the default settings. I am also having an issue with Error 12: Preset Not Found * Update readme.md
…/WLED into PIR_Switch_Enhancements
@albarlow looks like my recent update messed commit history (as 0.14 has been merged to main). |
I am not really sure that retaining HA discovery message is good idea. |
Hi, I'm happy for you to go ahead and merge it under your authority - I've had a bit of a look through and with the main branch having moved forward a version I don't want to mess anything up redoing it if you're in a position to just click ok and merge it. I think the rationale for retaining the discovery message would be that then WLED doesn't need to periodically resend the discovery message (which, given it doesn't need to update after creation, saves network bandwidth) and I'm not entirely sure what happens in Home Assistant if the message isn't retained. I used the same logic in my proposed modification as I did in the other usermod updates I put in PRs for. I'm happy to be guided by you on the matter of MQTT retention, as you probably have more experience than me... If you mean that you're not sure about including the Discovery Message logic at all, I of course defer to your authority on the matter, my use case for this is that I use home assistant, and the difference for a user who maybe knows how to breadboard together a D1 Mini, PIR and Lightstrip is that with the discovery message, the MQTT device appears in home assistant automatically ready for the user to work with. Without the discovery message, the user has to figure out the YAML to go and edit config files to create a manual sensor, which isn't part of a device and therefore not grouped with other relevant sensors. Seeing as the Discovery message can be toggled off, for non-home assistant users, it should have no impact on functionality for those who just want the sensor to use internally? What would have been the ideal solution for my aim in putting the disovery message in would have been to have usermod sensor data be able to appear directly as sensors in the WLED home assistant integration, but I think I can make a good guess why that isn't an option. |
I was merely curious as why retaining a HA discovery message. It will allow HA to recognise already set-up WLED devices without them needing to broadcast discovery messages periodically, though. |
Sorry - I probably got a bit overzealous in my previous reply...not being sure about whether the retention was the MQTT retention or the retention of the code I was covering my bases :) With the device discover messages all being within a homeassistant parent, that would hopefully make it unlikely that users would be subscribing to that key without it being home assistant or having some idea of its workings. |
Closing in favour of #2853 |
I have added Home Assistant Discovery option (toggleable in Usermod screen).
I also created an Occupancy timer that is only used for external reporting.
Future enhancement could be it include the occupancy timer in the JSON reporting display and being able to turn the occupancy sensor on/off.
I was testing this for around 6 months and it was working well. I've updated it today to replace changes made to the upstream version since.
I amended the MQTT publish procedure but have, so far as I can see, preserved the original functionality.