Since battery indicators (icons) came up in Homeduino and MySensors devices I also would like to have it in Variables Devices. E.g. usefull for sensor data coming in via REST-API from battery powered ESP sensors.
-
Battery type for Variables Device
-
I have implemented a proposal to support iconfied attributes for VariablesDevices. For the time being it is just proposal for discussion and review. If you want to trial it you need to install as follows.
cd /home/pi/pimatic-app npm i pimatic/pimatic#variables-device-icon
Here is my test case.
Device Configuration
{ "id": "variable_device_temp3", "name": "TemperaturImFlur", "class": "VariablesDevice", "variables": [ { "name": "myVariable", "expression": "roundToNearest($weather.temperature,0.5)", "type": "number", "unit": "°C" }, { "name": "myBattery", "expression": "$batteryLevel", "type": "number", "icon": { "noText": "true", "mapping": { "icon-battery-empty": 0, "icon-battery-fuel-1": [ 0, 20 ], "icon-battery-fuel-2": [ 20, 40 ], "icon-battery-fuel-3": [ 40, 60 ], "icon-battery-fuel-4": [ 60, 80 ], "icon-battery-fuel-5": [ 80, 100 ], "icon-battery-filled": 100 } } } ] }
Device View
Variables View
"It always takes longer than you expect, even when you take into account Hofstadter's Law.", Hofstadter's Law
-
That’s a nice proposal. I like it.
But would it be possible to “shorten things up” and include the mapping directly into the framework somewhere?
So maybe it would be possible to just set an attribute “battery” : “yes” or maybe a number for different filling states like
"battery" : 2 for 50 and 100% filling or
"battery" : 3 for 33/66/100% filling,
“battery” : 4 for 25/50/75/100% filling and
"battery" : 5 for 20 /40/60/80/100% filling?
Would ease things up imho.
But maybe complicated for coding?pimatic v0.9 has been released!
Support Pimatic and get some free stickers
Like us on Facebookmake it so !
-
@leader21 I agree the configuration is perhaps too complex for the average user. However, this feature is only required by power users, I believe
Seriously, the icon definition used in my proposal is generic and can be applied for different types of values, e.g. map the presence value to red and green traffic lights. So, it is not limited to this battery level thingy.
Compromise: To help the average user using advanced features we can integrate a simple template mechanism with pre-defined icons. Suggested approach:
Using predefined mapping
{ "name": "myBattery", "expression": "$batteryLevel", "type": "number", "icon": { # template can be an enum type, the user can simply choose from with the new device editor # the mapping is fixed, however. Assuming a percentage value for the numeric battery level # 99% of the user should be happy with this. If the value is not a percentage, e.g. # a capacity in Wh, this can be easily mapped to a percentage value as part of the "expression" "template": "numeric-battery-level-indicator" }
Using cuctom mapping
{ "name": "myBattery", "expression": "$batteryLevel", "type": "number", "icon": { # if template is set to "custom", the user defines the mapping "template": "custom" "noText": "true", "mapping": { "icon-battery-empty": 0, "icon-battery-fuel-1": [ 0, 20 ], "icon-battery-fuel-2": [ 20, 40 ], "icon-battery-fuel-3": [ 40, 60 ], "icon-battery-fuel-4": [ 60, 80 ], "icon-battery-fuel-5": [ 80, 100 ], "icon-battery-filled": 100 } } }
"It always takes longer than you expect, even when you take into account Hofstadter's Law.", Hofstadter's Law
-
Sounds good to me
pimatic v0.9 has been released!
Support Pimatic and get some free stickers
Like us on Facebookmake it so !
-
What is the state of the proposal?
-
@Heizelmann We had a follow-up discussion on this on Google Hangouts. I’ll summarize the results on the other thread soon and I will prioritize the implementation of the feature.
"It always takes longer than you expect, even when you take into account Hofstadter's Law.", Hofstadter's Law
-
"It always takes longer than you expect, even when you take into account Hofstadter's Law.", Hofstadter's Law