Skip to content
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

Closed
wants to merge 1,256 commits into from
Closed

Conversation

albarlow
Copy link
Contributor

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.

@blazoncek
Copy link
Collaborator

Occupancy is not a function of PIR (motion) sensor.
You can configure your HA to mark room as occupied if there is a motion in it within your desired time.
This will not get merged as is.

@albarlow
Copy link
Contributor Author

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.

@albarlow
Copy link
Contributor Author

Okay...I've reverted my original commit and submitted a new one with only the HA Discovery elements. Does that look more suitable?

blazoncek and others added 27 commits August 8, 2022 15:56
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.
blazoncek and others added 14 commits October 18, 2022 20:54
* 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>
* 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>
Aircoookie and others added 7 commits October 21, 2022 03:56
…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
@blazoncek
Copy link
Collaborator

@albarlow looks like my recent update messed commit history (as 0.14 has been merged to main).
Could you close this PR and open a new one and just include my recent update to PIR_sensor_switch.h? This way GH will honour your contribution. If you do not mind that then I can just commit updated PIR myself.

@blazoncek
Copy link
Collaborator

I am not really sure that retaining HA discovery message is good idea.

@albarlow
Copy link
Contributor Author

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.

@blazoncek
Copy link
Collaborator

I was merely curious as why retaining a HA discovery message.
Retained messages are permanently stored on MQTT broker and if not used cautiously they may incur additional network traffic as they are always sent to a new subscriber.
They may also be difficult to remove for inexperienced users and cause broker database increase needlessly.

It will allow HA to recognise already set-up WLED devices without them needing to broadcast discovery messages periodically, though.

@albarlow
Copy link
Contributor Author

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.

@blazoncek
Copy link
Collaborator

Closing in favour of #2853

@blazoncek blazoncek closed this Oct 26, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.