ValueError: could not convert string to float: ‘3142.866 W’
I’ve slowly started to update my items with correct UOM but do I really need to start splitting all values with .split(“ “) to get rid of the quantity type?
You can get C type behavior (i.e. ignore anything that cannot be interpreted as a float) by using
def scanf_float(s): num = [ ] for c in s.strip(): if c in “±.0123456789”: num.append(c) else: break return float(‘’.join(num))
To my understanding, the best approach is to use a standard unit for any item access by setting the unit in the item definition. Using text files, it will look something like this:
Thanks for answering! Well I would like to avoid using a custom function for every value retrieval even though that would fix the “problem”. Just hoped there was something I missed or not doing right using the internal functions of Habapp
I’m not sure what you mean by setting the unit in the item definition? That is what I have done as stated above?
Sorry, I missed you had a proper item definition already. Probably related to “Group” and the way the value is set…
I have plenty of items I simply access using .value and (sometimes) .unit. When accessing .value, I get a float for Numbers. In your case, it looks like you are getting a string including the unit. In this case, you’d need some conversion like the function shown.
I’d investigate which type is used for your group items next.
Indeed I did and I think there was something here. Earlier today I was testing a couple of items (in the group) with a transformation for rounding ([profile=“basic-profiles:round”]) however that made a mess so I reverted it and didn’t give it another thought. But it seems something buggy happened with the groupitem (probably making it a string type). Restarting both instances and resetting the group value (forcing it to to an int, 0) seems to have fixed this now.
No - the value should already be a float and have a unit property which carries the defined unit.
It definitely works with NumberItem - have you tried it there?
Maybe it’s an issue is with an UoM-Group … .
I’m not sure if I understand correctly. Is it now a float for you or not? You shouldn’t even need to cast it to float for most use cases.
I theorize that after I added “[profile=“basic-profiles:round”]” transform to a couple of my items in the group, made the group SUM value a “string” or corrupt somehow. But everything is working fine now after removing the profile/transformation
I usually float the value retrieved (when doing math operations) to ensure I don’t get any type problems, it’s probably unnecessary but just a precaution
@Spaceman_Spiff I’m not sure if this is a bug or not but something to notice perhaps….It seems that if I read a UOM value in a rule that’s executed on start (explicitly when Habapp is starting, does not happen on a rule reload) its read as a String (using Openhab.get_item(““).value)
The item in question (it has multiple members, all members are Number items):
I did a simple check of instancetype when loading and after it changes through a “change event” and everytime I reload HabApp the item is read as String, however as soon as the group value is updated through one of its members its back to Float and stays Float (until next reload).
if isinstance(OpenhabItem.get_item("gTotalHeatingWatt").value, str):
log.debug(f"DEBUGGER-TEST: '{OpenhabItem.get_item('gTotalHeatingWatt').value}' is a string.")
elif isinstance(OpenhabItem.get_item("gTotalHeatingWatt").value, float):
log.debug(f"DEBUGGER-TEST: '{OpenhabItem.get_item('gTotalHeatingWatt').value}' is a float.")
Log output on start:
MyRule] DEBUG | DEBUGGER-TEST: ‘426.409 W’ is a string.
