- 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
In case of different boil kettle, sensor from first kettle was used by external recipe import. Thi sis now fixed.
In case of different boil kettle, Sensor specified for this kettle will be used during external recipe import
-> 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
- bumped Version to 4.0.0.56
- Uncommented on push_ update in basic_controller2.py which seemd to cause error messages during startup and is not required
- 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.
- cbpi is now checking if a zip is existing to restore the config during start.
- If zip is there, content is checked prior to restore
- if required content is found, config folder is removed and zip is extracted.
- afterwards zip is removed
- cbpi is starting with restored config
Version -> 4.0.0.38
- 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
cbpi service can be activated via sudo cbpi add autostart
Service can be disabled via sudo cbpi remove autostart
sudo cbpi setup has to be triggered once -> this copies the craftbeerpi.service file to the config folder
- 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.
Timer was not accurate as it was depending on the asyncio.sleep function which is most liklely not exactly one second depending on other functions running in parallel.
Now the timer is comparable to cbpi3 where it runs until an end time is reached.
This is to address issue #66 and has been tested