That did it, works again. 
Thank you Bob. As always, you’re an absolute wizard.
1 Like
Has this integration with Home Assistant been incorporated into the main release branch of your code, or do I still need to add the hass service with the :develop notation, as seen above?
If the former, then it would be great to have in the documentation. Maybe I can help there.
Mylo
The hass service has an edge branch (the default value for ${BREWBLOX_RELEASE}).
Right now it’s useful, but still a proof of concept until we get around to implementing a more specific version.
- Do we want to export all sensors, or restrict to sensors listed in some configuration format?
- Do we want the eventbus to handle the bridge to the Home Assistant eventbus, or should the hass service connect directly (right now, it’s the second)
- Do we want to offer write functionality for Setpoint, Actuator, and/or PWM blocks?
Ok, I’ll way in.
-
I’d give the user the ability to choose which sensors to export via configuration. A analogous and somewhat elegant format for this is for what home assistant uses to allow you to choose which entities to visualize in the history function. Entities are categorized by domain - such as light, switch, cover (garage doors, window shades, …), etc. And by adding some yaml config to home assistant, you can explicitly allow or disallow entities, the entire domain of entities, or a combination of both. The concept of domain in BrewBlox could be “block type” - like PWM, Actuator, Setpoint, Setpoint Driver, etc…
-
I’m not sure what the pros and cons are of this design decision - however I would pick whichever one was more “stable” for both platforms, if possible.
-
Of the three listed - having the ability to change set points would be amazing. I doubt that I would ever replace the PID logic with a Home Assistant automation, and therefore would not need to set PWM values directly. I could see someone, however, wanting to turn on or off a fan or something else - so the next priority of write functionality could be the actuator, itself.
If we’re adding configuration, it’s either static configuration in a brewblox/hass/ dir, or it gets stored in the Redis config database. The latter is nicer, but requires UI integration, as otherwise people would need to make manual curl calls to read/write configuration. If we’re adding UI integration, we’re also making a somewhat more definitive statement on the level of support for the hass service.
I’m not sufficiently up to speed with Home Assistant classifications and groupings to predict anything there - the current implementation is a least-effort proof of concept, and my reading of the Home Assistant documentation has been correspondingly brief.
Mosquitto bridge vs dual eventbus connection mostly impacts where the connection parameters (including password and/or auth key) for the Home Assistant eventbus are stored. I’m predisposed towards creating a mosquitto bridge because the configuration is more stable, but any connection failure would be invisible to the hass service. You’d have to look at eventbus logs to see connection / auth errors.
Direct PWM control for things like fans can be useful (turn on a fan 50%, instead of fully on).
I’ll have a look at the domain thing you mentioned, and discuss with Elco how much time we’re willing to invest in Home Assistant integration. We can then hammer out a set of features that are both desirable and doable.
For my needs, I really don’t see much use beyond what’s there. I built a dashboard in Home Assistant that shows my fermenter Temp vs Setpoint, my Tilts from a TiltBridge, my glycol temp from Brewblox, and my kegerator temp from an Inkbird bluetooth thermometer. Anything further, there’s a button to open BrewBlox.
I’ll add one more thing. It would be great if there was a bool value that reported whether a profile was enabled on each of my fermenters. That would allow me to determine whether the fermenter was in use at a given time.
That seems universally useful enough to add. We’re also adding a readonly outputSetting field to the Setpoint Profile block, with the setting it’s currently pushing to its target.
Would you prefer a boolean value, or a temperature value (null if outside profile or no target)?
I’d prefer it to be a bool saying its active or not. Home Assistant already reports Unknown as the setpoint which kind of works for some dashboard work I’m doing but its not ideal.
Bob,
I am having issues with no data getting to HA anymore since updating today. log located here: https://termbin.com/18vrk
brewblox-hass-1 | 2023-04-20T01:04:58.552214198Z 2023/04/19 18:04:58 ERROR brewblox_service.mqtt Exception handling MQTT callback for brewcast/state/spark4: TypeError(payload must be a string, bytearray, int, float or None.)
I pushed an update to resolve the problem. To get it, run:
brewblox-ctl service pull hass
That corrected the problem. Thank you!
You Rock !
It’s very usefull
Any update on adding the profile active outputs?
We added the required setting field to the profile block, but apparently didn’t create an issue for the hass service implementation. Thanks for reminding me! I’ll make sure it’s included in the next release.
1 Like
I never did see this show up. At the time I had batches in both fermenters and figured maybe it would only be sent on change but now I’ve played with it on an empty fermenter and still don’t see it. Was it in the last release or still the next coming up?
This is live. The state is published as a binary sensor. If you check the logs for the hass service, it should print a message “publishing new profile state: {id}”.
Yep, its there. I’ll have to dig into who Home Assistant isn’t showing the entities.
I could see them using MQTT Explorer inside Home Assistant. I’m not positive this was the problem but my profile names had a - in them unlike all the other block names. Renamed them and they instantly showed up.
We do a text replace to generate valid entity names from block IDs. Currently It allows alphanumeric characters and _-. I’ll remove the - from the allowed characters if it’s an issue.