V1.1.11 Home Assistant Discovery, EG4 Protocol Definition, and other small misc Improvements

[Tmaxxrox97]

Home Assistant Discovery

• Switched from component discovery to device discovery which allows the discovery messages to get sent out faster.
• Added additional discovery attributes such as platform, device class/state_class
• Added default discovery messages based on register unit
• Setup automatic handling of writable registers as inputs in Home Assistant with number entry, buttons, and switches being handled appropriately based on available values
• Defaults are able to be overwritten based on the entries in the protocol definition file as needed

EG4 Protocol Definition

• Updated some ranges/values to align with FlexBoss21 defaults and it passes the 90% test. Not all have been tested however.

Other Misc Stuff

• Protocol write validation now accounts for unit mod
• Protocol write validation now accounts for allowed values in addition to ranges i.e. 0,10-90

I think that's all but I might have forgotten something.

[Tmaxxrox97]

This should address #121 with "Protocol write validation now accounts for unit mod"

[HotNoob]

i'm not sure if "- 1000W~1000W" is correct.

"-1000~1000"

might work better

[Tmaxxrox97]

Yeah this was something I was trying to get work to help with the protocol validation because it wasn't handling the -1000 as a negative and the allowed range just ended up being 1000 to 1000 instead of -1000 to 1000.

Adding a W makes PPG treat it as ASCII and it ends up just bypassing the check.

Not intentional to leave that in so it could get switched back to how it was. I might also spend a bit of time to get that parsing work correctly.

[HotNoob]

df7be15
should allow -1000~1000 ( untested )

variable types already ints, so should work i think...

but, something like -1000~-250 is a problem... for now.

[HotNoob]

"0,400-590"

combination of lists & ranges.
not sure if ppg handles this properly.

[Tmaxxrox97]

I changed this section to add the allowed values as a possibility also. The parsing of a list and range was already done here.

[HotNoob]

ahh, nice, i guess it is already there... hopefully i have the logic done right as well :S
i donno how thorough past me was.

ed6462c
( add neg fix to list ranges )

[HotNoob]

i think this should be in requirements-dev.txt?

[Tmaxxrox97]

I added this so that I could read the pyproject.toml file directly to get the project details for mqtt discovery. See here and here

data = project_details()
origin = {}
origin["name"] = data['project']['name']
origin["sw"] = data['project']['version']
origin["url"] = data['project']['urls']['Homepage']

There's probably a better way to go about doing this.

Looking at the Dockerfile, pyproject.toml doesn't make it into the Docker Image so this method doesn't work for that unless the Dockerfile is updated to include it.
It also probably wouldn't work when installed using pip install python-protocol-gateway either.

Do you have any thoughts on the best way to handle this? Hardcoding this info is an option but then you'd have to update it in 2+ places. importlib.metadata is an option when its installed through pip but a check could maybe be added for when it isn't? Or including the pyproject.toml file in the places it needs to be referenced is also a possibility.

[HotNoob]

very nice. just did a quick light review.
added a few comments, maybe some stuff todo.

i don't fully understand how the "enabled_by_default: false" thing works.
i think i saw some regex added for bool parsing? so "enabled_by_default:" just gets cut out?
should be ok then.

i haven't had much time for ppg lately. busy.

thanks for the contribution!

[Tmaxxrox97]

i don't fully understand how the "enabled_by_default: false" thing works. i think i saw some regex added for bool parsing? so "enabled_by_default:" just gets cut out? should be ok then.

From the Home Assistant Side:
enabled_by_default true/false tells Home Assistant whether the entity should be tracked or not by default. It's essentially a middle ground between not sending the data at all (through the use of PPG's masking) and having every entry shown in the list in HA. PPG still sends the data over MQTT so something else could use it but HA doesn't pay attention to it by default. There's the option in HA to manually enable it if someone wanted.
Here's an example from a motion sensor I have. Voltage is enabled and therefore has a value but linkquality is not enabled and is greyed out with no value. The data is still being sent over MQTT though.

From the PPG Side:
The default I added was to have every entity enabled. See here
disc_payload["cmps"][unique_id].update(dict({'enabled_by_default': 'true'}))

This then gets overwritten by anything defined in the protocol CSV file in the ha disc column a little later. See here
disc_payload["cmps"][unique_id].update(item.ha_disc)

This lets people enable/disable things by default that they want sent over MQTT but not ingested by HA or to set different discovery settings if the default by unit isn't correct or isn't included. In the end the CSV file wins.

i haven't had much time for ppg lately. busy.

No worries. Life gets busy for sure. I had planned on making this PR a few weeks ago but got delayed by various things.

thanks for the contribution!

Of course! I'm excited to be able to use this with my inverter and Gridboss and these changes are going to make it easier to do.
Are you planning a release of PPG anytime soon? Assuming this and my other PR are merged, v1.1.11 is going to have some changes that are important to me. I could obviously run off my fork but I'd prefer to stay with the main project.