Good news everyone!
I just released HABApp 0.30.2!
Hey all,
i am working on my electric energy counter system and i am wondering if it is possible to work with units of measurement in HABApp.
I get electrical consumption value in Wh and it would be nice to use oh measuerement conversions i.e. to kWh
Any hint on that?
Currently that is not supported.
You can either
Thanks for the info.
Just an additional information from my side. HABApp retrieves the converted values from openHAB if UOM is used in openHAB.
I know that my sensore deliveres Wh and for better readability i added a state description to this item. Now it displays kWh.
Number:Energy SH_EnergyMeter_MeterSensor
"Sensor StromzÀhler"
<measure_power_meter>
(SH_EnergyMeter, gFG_PS_TimelineData)
{channel="homematic:xxxxx:1#ENERGY_COUNTER", stateDescription="" [pattern="%.2f kWh"]}
Before adding the state description HABApp receives Wh values after adding the state description HABApp is receiving kWh.
Seems to me that HABApp redas the transformedstate instead of state.
@Spaceman_Spiff Am i right with that?
Question on persistence data.
If i get it right it is possible to retrieve data within a defined time frame (starttime - endtime). If there is no value within this frame the result is empty.
If i read the api calls right, there is an option to specify that a value right an left from the intervall is retrieved. I find this very usefull, because often i like to retrieve a special point in time. with the option to retrieve the values right and left i could use the average.
Is it possible to extend the persistence function?
Unfortunately the Rest API does not specify which value is transmitted with the SSE event but I guess youâre right.
Sure - everything is possible! Itâs just a matter of doing.
If you like this as a feature you can create an issue with a thorough describe what you want.
Iâll see if I can implement it.
In OpenHAB DSL there is an event âSystem startedâ.
Can something similar easily be implemented in HABApp?
(i.e. it is triggered when HABApp is restarted.)
Today I do like this:
class MediaCenter_Volume(HABApp.Rule):
def __init__(self):
super().__init__()
self.mcVolumeItem = DimmerItem.get_item( 'MediaCenter_Volume' )
self.run.soon( self.update )
self.mcVolumeItem.listen_event( self.update, ValueUpdateEvent )
def update(self,event=None):
mcVolume = self.mcVolumeItem.get_value()
...
Ideally I would like this:
class MediaCenter_Volume(HABApp.Rule):
def __init__(self):
super().__init__()
self.mcVolumeItem = DimmerItem.get_item( 'MediaCenter_Volume' )
self.mcVolumeItem.listen_event( self.update, SystemStartedEvent | ValueUpdateEvent )
def update(self,event):
assert isinstance(event, SystemStartedEvent | ValueUpdateEvent), type(event)
mcVolume = self.mcVolumeItem.get_value()
...
Another approach could be if HABApp called ValueUpdateEvent for all items when HABApp is started,
but that may lead to poor performance.
But what you do is different than what would happen with a system started trigger.
The function update
will also be called once you reload the rule (e.g. when you make changes to it) and thus properly initialize everything. A SystemStarted
trigger would only be executed once.
For me itâs hard to imagine a use case where a SystemStartedEvent
is needed because it will not trigger on rule reload.
Imho:
If you put it at the end of the init block, it doesnât look so bad âŠ
class MediaCenter_Volume(HABApp.Rule):
def __init__(self):
super().__init__()
self.mcVolumeItem = DimmerItem.get_item( 'MediaCenter_Volume' )
self.mcVolumeItem.listen_event( self.update, ValueUpdateEvent )
# Initialize
self.run.soon(self.update)
def update(self,event=None):
mcVolume = self.mcVolumeItem.value # If you don't supply a default
... # you can use .value
Yeah, you are right about reloading the rule, I didnât think that way. I will keep my current setup!
Thanks for you input!
Imho the âsystem startedâ trigger does only exist, because itâs not possible to run code when the file is loaded. So the idea was to provide some sort of initialization mechanism.
With HABApp this is natively possible so there is no need.
Today i optimized my thermostat rule. Exchanged the group approach with parameter files. Used the reload on parameter. General approach is to create listeners instead of creating more than one class instance. Nice, Nice, Nice!
In another rule if have additional parameters in a parameter file like offsets. These parameters should be accessible within a listerner function. Due to the fact that i am at the very beginning with python, i have no clue if it is possible to add additional parameters to the listerner function
class MeterManager(HABApp.Rule):
def __init__(self):
super().__init__()
self.meter_reset.listen_event(self.reset_total_consumption(offset=12), ItemCommandEvent)
def reset_total_consumption (self, event: ItemCommandEvent, new_offset):
#Do something with offset
pass
Is that possoble or is there a best practice on that?
Thansk for the help
Iâd create multiple rule instances from the parameter file:
class MeterManager(HABApp.Rule):
def __init__(self, name: str):
super().__init__()
self.my_param = HABApp.Parameter('MyMeters', name, 'offset')
self.meter_reset.listen_event(self.reset_total_consumption(offset=12), ItemCommandEvent)
def reset_total_consumption (self, event: ItemCommandEvent, new_offset):
#Do something with offset
if self.my_param > 1:
pass
for name in HABApp.Parameter('MyMeters').value:
MeterManager(name)
MyMeters.yml:
name1:
offset: 12
bla: bla
more: config
But you can always use lambda functions or functools.partialmethod
@Spaceman_Spiff Thanks for your answer.
My question is answere and i could continue with my rules.
But and there is always a but, i recognised that you propose another differnet approach. Thats always the fun in programming for me - so many ways to the goal.
At the end i see two fundamental approaches:
1.) Create multiple instances as you suggest and i have done too
2.) Create multiple listeners based on a parameter file as i have done as well
What is the preferred way? Or is it just a question of personal thinking. What are the benefits from one solution over the other.
I like to group logic that belongs together in one rule.
E.g. I have a rule class that does the shutter automation (up in the morning, down in the evening) and then I instantiate it for every shutter I have.
Additionally I have a rule class that shadows when itâs hot so I instantiate it, too for every shutter I have.
Both rule classes have multiple listenes
Itâs not âeither orâ but rather a mixture of both.
Try building logic blocks and reuse them.
I see your point . Combine some logic in a rule and instantiate it for every item (thermostat, shutter, window, âŠ). I think to do it in that way has some benefits.
Thanks
And another question to which i did not find a answer.
Is it possible to set the label of an item using HABApp? My use case is to label status items of plant sensors. These should be set dynamically, because plants ar dieing fast âŠ
With self.oh.create_item
it is possible to create/update items.
Be aware this will not work if you created the item in a file.
Thanks. Hmmm then i have to find another solution. i hate al those shortcomings of openHAB sometimes.
But i get mor and more used to HABApp
Maybe itâs possible to combine two items to one with an openhab3 widget.
But Iâm not sure since I havenât migrated yet.
With the new Main UI i have solved that, but for my smartphone i prefer the old Basic UI. At the end there are onyl 15 sensore with that requirement. And not changing my sitemap put pressure on plant care