Why? You ask me why? Because I want everyone in my family to have access to those files.
## How about changes?
The general rule about changes is that you can intruduce them yourself and put in a pull request. However, withhin the family I will try to continue and improve stuff as it is so should you have suggestions, I'd like to hear them
## How about passwords and keys?
Passwords and keys are listed in (secrets.yaml.temple)[this template]. We do not have a way to share the actual secrets.yaml internally within the family but I hope we find a solution to that problem. For now, ask me and I may share it with you.
This is a standard config for the a3pool. Nothing special by far with 2 temp sensors and 1 switch.
The temperature sensors have the `pool_temperature` and `solar_temperature` and will show report the pool temperature and solar temperature respectively every 10 seconds.
There is also one switch that is designed to turn the pump on and off. This works by giving an 500ms long impulse that should turn the pump on/off and sensing on a GPIO ping whenever the pump is currently on/off. This switch carries the name of `pump`. I know HOW CREATIVE...
It also has the possibility of having it's own clock.
Simply adjust the time using the `start_h`, `start_m` as well as `end_h`, `end_m` and enable the `control` switch to ensure the automatic control in on. The button `sync_to_clock`is used to sync the system back to the clock without having to know/care about on/off times, simply press the button and it should switch to on/off if it should be on/off respectively.
**HOWEVER: If the pump is set to off or to the physical clock with physical switch in the garage this will not work!** It will still report it's state correclty however.
# Table Tennis Count!
## Table Tennis Footswitch
The files go by the name of (pingpongfuss.yaml)[pingpongfuss1.yaml].
While the 1 may be interpreted as just the first of the two sides, it's actually just one nodemcu for both sides. So keep that in mind.
And other disclaimer: **This does not use the native API, or an encryption key, and uses MQTT only. However, that might change in the future**
The topics are as follows:
### Scoring points
Topic `tabletenniscounter/control/score/count` will be send with the value of either `0` or `1` when ever red or blue should get a point respectively.
### Undoing last points (Up to 10 points)
Topic `tabletenniscounter/control/score/undo` will be sent with no payload to worry about. The counting part on the respberry pi is supposed to keep a list of the last 10 points.
This is probably the more exciting bit about this. It's the part that actually displays the numbers on the display. The part, that tries to displays all the numbers in a way people can use it to read their current score.
We have a LOT of stuff of stuff to discuss here.
First of all: It does take advantage of custom components. CustomMQTTDevices to be precise.
Second of all: It uses the NeoPixelBus Library to communicate with the ledstrip.
Third of all: It does also use the esphome native api.
And a disclaimer as well: The native api part was the latest thing added and is by no means ready to be used. In fact it is only used right now to publish the current score to home assistent but nothing else as it cannot display the numbers sent to the esphome over the native api. This feature is planned but not yet implemented tho.
For the MQTT part we have only one topic to worry about.
### MQTT JSON message
MQTT topic `tabletenniscounter/display/number/command` is used to send the score that should be display encoded as a JSON message. So let's go over the different key/values attributes.
- state => "ON"/"OFF": This must always be included and must be ON if any other fuctionallity is intended to be used as OFF is going to turn the ledstrip OFF no matter what
- player1 => Number 0 - 99: This tells the display the score of player red (which is also the left number). This MUST be used together with player2 and player1Start/displayGreen.
- player2 => Number 0 - 99: This tells the display the score of player blue (which is also the right number). This MUST be used together with player1 and player1Start/displayGreen.
- player1Start => true/false: This if this is used to display which player is supposed to start. If the value is true, the colon between the two numbers is displayed as red, if it's false, the colon is blue. This attribute can be replaced with displayGreen.
- displayGreen: The value for this does not matter. If it's there, the colon is green.
- player1Winner => true/false (OPTIONAL): Set this to true, and player 1 (red) will be displayed as the winner by displaying the red number as yellow. If it's false, player 2 (blue) will be displayed as the winner. Omit this attribute if no one should be displayed at the winner.
Should state ON be sent without any other attribute, the nbs logo is displayed with a little minus at the end for no particular reason.
Ledstrip Simple is a basic implementation of a ledstrip using no custom code and works solely on the addressable_ledstrip implementation of espHome.
There are a few light effects configured so please play around with them for a little. Have fun.
There is one thing I should mention tho:
At line 34 in the ledstrip_simple.yaml there is a number called num_leds which dictates how many leds there are on the ledstrip. Please change that according to your ledstrip.
Second of all, if you want to change the door, just change the `garageSide` under `substitutions`. It's either `sy` or `wo`.
Then let the custom components do their job I suppose. They are under [external_components/hoermann_door](external_components/hoermann_door). The [__init__.py](external_components/hoermann_door/__init__.py) needs to be there while the [cover.py](external_components/hoermann_door/cover.py) and [output.py](external_components/hoermann_door/output.py) make the platforms in `cover` and `output` available.
