You have to post a datetime or whenever datetime object to the DateTimeItem. datetime.parse(str)
I think I could extend the value validation so that if a string is passed parsing to datetime is tried. What do you think? Did you stumble over other validation issues?
Edit: @usambara
I’ve created DEV2 which accepts str for datetime items.
It parses str to see if it’s a valid datetime input and then creates the event.
I also added a warning for the config entries.
Out of curiosity - what were you using the OnOffValue for?
i try since 2 days to get the new 25.2.0.dev1 to work but still have no success.
at first i also had to remove
openhab:
connection:
# buffer: 256kib # try to fix boot error "ValueError: Chunk too big"
from config.yml
next i had a lot of errors because e.g. i sent strings to numberitems instead of integers. good to know there was something not correct and this shoud be fixed an ok now.
but still have issues that i am not able to find. i see no errors in the logs, but the result is a for me really strange behaviour: i see some activity in the habapp logs, so some parts seem to work, but when i just try to switch a light with self.oh.send_command('iEGFlur_Dekolampe', 'ON') nothing happens. i am afraid it is becaue of some async functions that worked till now. sometimes the system works for some time after a reboot and sometimes it even does not start completely.
i will try to investigate more and come back when i have news. actually not a problem at all because i just go back to version 24.11.1 and everything works again
Is this is proper use case or was this unintended from your side?
What do you mean by that? Do you think it’s a rule issue or a HABApp issue?
Would it be possible that you can create a small example with which I can reproduce the issue? self.oh.send_command has an additional parameter which you can set to http to get the old way of sending data to openHAB. However if see nothing in the log I doubt that this is the root cause (because invalid data or data that is rejected would generate a log entry).
You can also PM me for further assistance.
It’s because openHAB never reaches start level 100. If you check your things there is probably something still pending.
Also check your HABApp configuration - there you have a config entry which defines at which openHAB start level HABApp starts. The default is 70, but 100 is better because there the startup and restore is complete. However openHAB often has issues reaching 100 and I’m not sure why.
There is also a timeout running so HABApp will start eventually (I think its ~10min) even if the start level is not reached. I’ll add an additional fallback so HABApp doesn’t check the start level if openHAB has been running for some time.
ok so will try the update again. for me it was strange because with oh 4.3.2 it reaches the 100. and i am pretty sure the timeout was much less than 10 minutes, i suppose it was 2 or 3.
i intended to set this to 100 because i felt some rules do not work correct or even crash on start if some items are still not initialized.
There are two timeouts: min uptime which waits unconditionally for a certain openhab uptime.
Then there is min start level which waits for a start level after waiting for the uptime.
In case openHAB hangs again and doesn’t reach level 100 at level 70 an additional timeout is started. After some long time HABApp will start even if openHAB never reached the configured start level.
You see the start of this timeout in the attached log:
so i again updated oh to version 4.3.3 and now realized that the webhook-binding got lost during the update. this caused the webhook thing to a handler error. i installed the binding again and now the system starts. i still see the timeout in the habapp.log a little more than 2 minutes after the log starts:
Thanks for the DEV2, I will test it soon.
I’m using the OnOffType almost everywhere where I post a constant value to a SwitchItem. It shouldn’t be to hard to replace it.
The OnOffType is used in about half of my rules, which aren’t loaded now. Therefore it is difficult to say if there are other breaking changes as well.
If you want to send a command you can use .on() and .off().
For posting update you have to use a string ('ON' or 'OFF').
Maybe it makes sense to introduce a OnOffEnum which is also a str?
What do you think?
I frequently do this because it is common to add a unit for UoM NumberItems. Something like item.oh_post_update(str(energy_value)+“Wh”) I have not yet installed the beta, but has this been changed?
As a general rule for all post_update() and send_command() calls, I’d suggest to support at least what can be done in Rules DSL. I’m aware openHAB is just one of two models HABApp supports. However, migration / porting back and forth is a lot easier in case you do not need to change every line of code.
You should set unit in the metadata and then it’s not required to provide the unit.
If you send the number the configured unit is automatically assumed.
If you are keen on providing the unit you have to add a space: '13.0 Wh'.
This continues to work as expected.
It’s either int / float or a str with value and space and unit.
So in your example this would be
item.oh_post_update(f'{energy_value} Wh') # <-- note the f-string which I would recommend
item.oh_post_update(str(energy_value)+“ Wh”) # <-- note the space befor Wh
Yes, I had added units to the metadata for all NumericItems with a dimension / type. The nice thing about setting the unit is that this results in an auto conversion according to the metadata unit. I do a lot of power and energy calculations. UoMs are quite helpful here to deal with different manufactures using different precision / magnitudes.
I just checked all post_updates, roughly 50 with a unit added and only 2 without a blank.
I haven’t used enums so far, but after a quick look in the documentation, I think that this could be the right replacement for the OnOffType as I use it.
I have recently upgraded the HABApp version, and I noticed in the log
DeprecationWarning:self.run.every is deprecated. Use self.run.at in combination with a trigger
I checked in the documentation examples and I still found an exemple with self.run.every. Then, I went through this topic and I found an example of using self.run.at
I did not read all of the documentations, but in any case I would suggest to update the examples section of documentation.
I realized that every time I’m overwriting a rule file with another version I get a warning.
2025-02-23 21:59:32.767 [WARN ] [HABApp.Rules ] - Rule file /etc/openhab/habapp/rules/persistence/persistence_influxdb_lowlevel.py is not yet loaded and therefore can not be unloaded
At the first load at startup there is no warning, just the success message “added rule…”.
i think i had similar warnings that a rule still was not yet loaded some time ago. i realized that i run a method from the init that was not finished when i already reloaded the rule.
eg i had:
class ItemTimer(Rule):
def __init__(self, item, timer_item_name=None, timer_time=None, left_item_name=None, unit='m'):
super().__init__()
self.log = logging.getLogger('My_HABApp')
self.log.debug(f'Init HABApp.Rule ItemTimer.py for {item:s}')
...
self.boot_initialisations()
def boot_initialisations(self):
'''
Items checken ob nicht None / UNDEF - erst danach Funktionalität aktivieren
Listener für Dimmer bzw Switch aktivieren
'''
and the warning was gone when i simply changed the method call to
