- forces mqtt update for kettle and femrenter in specified timeframes even w/o change in payload
- required for mqttdevice
- only active if mqtt is enabled
- can be set to never and is also deactivated when mqtt is enabled
- Different names for fermentersteps as Notificationstep caused an issue (steps not yot implemented for fermentation)
- Reverted back item based mqtt as this may require further testing -> will be activated in dev branch later
-> sensor values are updated under sensordata/{sensorid}
One topic for each sensor to keep data small (esp compatibility)
actor, kettle, sensor, fermenter, steps are updated also for each id individually to keep packets small
e.g. actorupdate/{actorid}
This was proposed by Innuendo to ensure compatibility with the ESP based MQTTDevice
Added fermenter type
Added fermenter logic (incl. new class)
-> will require cbpi4ui -> >= 0.1.a1
Still under development, but fermentation w/o steps should be working
- Actor used to set power to 100 eventhough target was 0
- moved chromium.desktop file to config folder -> easier available for users and potential to enable chromium desktop via cbpi commandline in future
RPi.GPIO 0.7.0 is causing an error if installed under bullseye and python 3.9
-> 0.7.1a4 solves the issue for now.
-> will be changed as soon as new RPi.GPIO release is comming out
Power = 100: standard on
Standard sampling time is 5 seconds.
if power is set to 50%, heating time is 2.5 sec and witing time (gpio off) is also 2.5 sec
Changing power to lower readings, wil reduce heating time within the 5 seconeds and increase waiting time
Increase of power results in longer heating times and reduced wait times
Sort of a poos men's PWM with a fix requency of 0.2 hz
This will reduce the complexity of all PID plugins.
Some additional tests and changes might be required for api.
- Up to 10 Dashboards possible
- Config parameter max_dashboard_number added
- Default is 4 dashboards
- Config parameter will be added automatically via extension if not in config.json
- Added path parameter in config.json for settings
- If empty, 'upload' will be used per default as api path
- If something is entered, a different api path will be used for the creation of recipes.
-> this allows the standard usage of the recipe upload and selection via cbpi4, but adds the possibility that custom plugins can be written to create cbpi recipe flows from the uploaded files
*********************
+ some prep work to create the http endpoints
- Beerxml files and kbh V2 database can be uploaded to cbpi via webinterface.
- Recipes can be created from the xml file or the kbh database
- cbpi setup needs to be run to create upload folder
- config.json needs to be updated manually on an existing installation ro add the step config.
--> this could be added automatically via the extension. However, needs to be discussed with Manuel.
Tip: cbpi4-RecipeImport Plugin could be installed , activated and removed later as this plugin adds the parameters during startup including creation of the upload folder
Change is somehow dependent dependent on issue #68 with corresponding change in dataclasses.py.
But this is an example on how the change in dataclasses.py would allow to simplify the props handling in case of empty values.
If sensor is set to active, GPIO pin should be high under normal conditions.
If inverted, GPIO pin should be low when sensor is active.
This logic is aligned with the old craftbeerpi3 GPIOSystem plugin
