Showing this item in a sitemap, it displays as “3000 %”. I’m surprised that the item’s state has unit one, even though the item’s unit is %. I suspect that’s why when it gets displayed, it’s converting to percent again, and 30 is 3000%.
The linked channel is a vanilla Number type, so it makes sense that it’s sending a one unit type, I just thought that would get interpreted as the item’s unit on update. Perhaps that was part of CommunicationManager code that got ripped out?
I’ll check that. But it seems that the communication manager is doing too much here.
Edit: It works perfectly fine for me. I added the magic binding and linked the number channel of the chatty thing to a Number:Dimensionless item with metadata unit=“%”. Some updates are send as QuantityType with unit °C and rejected (because the unit is incompatible, which is correct) and the other ones are plain DecimalType between 0 and 100 which correctly results in
Checked the 4.0.0.0 Windows Install (and update) instructions nad don’t see anything there.
Please can you assist?
BTW I have reverted back to 4.0.0.M2 in the meantime.
EDIT:
Found this:
EDIT: Tried to run the UpgradeTool manually (from the TEMP folder and got the following:
PS C:\Users\p8900019\AppData\Local\Temp\openhab\update\runtime\bin> java -jar upgradetool.jar --dir c:\openhab\userdata --command itemCopyUnitToMetadata
Error: LinkageError occurred while loading main class org.openhab.core.tools.UpgradeTool
java.lang.UnsupportedClassVersionError: org/openhab/core/tools/UpgradeTool has been compiled by a more recent version of the Java Runtime (class file version 61.0), this version of the Java Runtime only recognizes class file versions up to 55.0
Thank you. You are right. Java 11 was before Java 17 in the path, even though JAVA_HOME was correct. I suppose because the command was (takes first java in path):
[main] INFO org.openhab.core.tools.internal.Upgrader - Copying item unit from state description to metadata in database 'c:\openhab\userdata\jsondb\org.openhab.core.items.Item.json'
[main] WARN org.openhab.core.tools.internal.Upgrader - ShellyEM_MAINS_TotalEnergy_Monthly: State description contains unit place-holder '%unit%', check if 'unit' metadata is needed!
[main] INFO org.openhab.core.tools.internal.Upgrader - ShellyEM_UPS_TotalReturnedEnergy: Wrote 'unit=kWh' to metadata.
[main] INFO org.openhab.core.tools.internal.Upgrader - ShellyEM_UPS_VA: Wrote 'unit=VA' to metadata.
[main] WARN org.openhab.core.tools.internal.Upgrader - ShellyEM_UPS_TotalEnergy: State description contains unit place-holder '%unit%', check if 'unit' metadata is needed!
[main] WARN org.openhab.core.tools.internal.Upgrader - ShellyEM_MAINS_TotalEnergy: State description contains unit place-holder '%unit%', check if 'unit' metadata is needed!
[main] WARN org.openhab.core.tools.internal.Upgrader - ShellyEM_MAINS_TotalReturnedEnergy: State description contains unit place-holder '%unit%', check if 'unit' metadata is needed!
[main] WARN org.openhab.core.tools.internal.Upgrader - ShellyEM_Mains_TotalEnergy_PreviousMonth: State description contains unit place-holder '%unit%', check if 'unit' metadata is needed!
This seems to imply further action is required?
And, does the UpgradeTool have to be run while openHAB is shutdown?
ok I want to report that I’m running 3460 and as in above post I’m still experiencing the cpu getting pinned occasionally. It used to take only a day or two but now it goes a week. It does not crash the box or OH but things get sluggish. (host i3 HDD 8GB Dell desktop Mint Linux)
When I restart the host, I must manually set safeCall to 100 (default 10) as describe by Cody here I have the script from the bottom of that same post and if I manually run it when the CPU is pinned it calms down after a few minutes.
I have RDD uninstalled and influx installed
I use DSL and Jruby rules 48 things 240 items
This problem seems unique to me so I’m guessing it is something in my config which is an OH3 upgrade. If anybody wants me to investigate further, I’ll do my best but eventually if no one else reports it (which no one seems to be) I’ll probably just wipe it and start from scratch load fresh clean install and start adding stuff back
Some weeks ago I updated the well running OH snapshot version on Raspi 4 using openhabian. This ended with the appended message . The system is completely locked afterwards. When I make a fresh installation and manually copy all files to conf and userdata, everything works fine until I do an update again. Is there anything I should modify or delete before I make an update or do I have to generate all items again. I only use UI installation.
The modified script and upgrade routines are now working. I had to setup a new system , cause I couldn‘t convince openhabian to restart the upgrade routines.
The only disadvantage I have now, is that all metadata are gone, no expire dates or state descriptions.
I just tried it in the old system, but there I couldn’t run the script. I will try it in the new system later on. What I forgot to say, that all units from z-wave devices are gone except for temperature . There is not Voltage „V“ for electric.potential
I made my first foray into openHAB 4 today. I loaded the SNAPSHOT 3842 using openhabian. I had previously updated to Java 17. It appears to have gone fairly smoothly.
The biggest obvious problem I experienced was when I went to add the smart home/j Tuya and AmazonEchoControl bindings. When I first went to the Add-on’s screen in the UI, the smarthome/j bindings were listed after the Community Bindings. A little while after I clicked on install on the AmazonEchoControl and Tuya bindings, there was an error message in the lower left hand corner. It didn’t stay, so I’m going from memory but it was something about JSON file error. After that, the smarthome/j bindings disappeared front the UI. I tried restarting openHAB, but that didn’t help.
I poked around looking for things that looked amiss. There are some references to 3.4 that seem out of place in:
I have a few rules I need to sort out. I thought I went through and opened all of my Blocklies and saved them, but I’m still getting a few Errors.
2023-05-28 18:12:29.454 [ERROR] [ipt.internal.ScriptEngineManagerImpl] - ScriptEngine for language 'application/javascript' could not be found for identifier: dd9beff2-1ccc-4b81-bac0-456fd51c723e
2023-05-28 18:12:29.513 [ERROR] [ipt.internal.ScriptEngineManagerImpl] - ScriptEngine for language 'application/javascript' could not be found for identifier: 26aebbf6-1481-4b97-b875-dba3d20e5f41
2023-05-28 18:12:29.514 [ERROR] [ipt.internal.ScriptEngineManagerImpl] - ScriptEngine for language 'application/javascript' could not be found for identifier: dbafca86-c651-4184-b303-9e7100185542
2023-05-28 18:12:29.518 [ERROR] [ipt.internal.ScriptEngineManagerImpl] - ScriptEngine for language 'application/javascript' could not be found for identifier: dbafca86-c651-4184-b303-9e7100185542
I can’t connect the identifier to anything that would help me figure out which rule is causing the error. Is there some way to do that I’m missing?
Sorry for the slow reply - I never saw your edit. But anyhow, I figured it out today. I was wrongly assuming that if you don’t have the unit metadata set, it would infer the unit from the state description. As for my debugging… I found a bug in the Ruby helper library that unit is possibly calling the wrong method. So yeah, I think it was just a few things wrong on my end, and it seems to be working now. Thanks!
openHabian clean install on rpi4 OH4.0.0 #3483 with just EnOcean binding installed.
EnOcean USB300 dongle is automatically put to inbox with correct port.
The port is available and working.
But after adding thing “trying to get bridge base id …” does not work.
2023-05-29 09:53:19.298 [INFO ] [ernal.transceiver.EnOceanTransceiver] - EnOceanSerialTransceiver initialized
2023-05-29 09:53:19.300 [INFO ] [ernal.transceiver.EnOceanTransceiver] - EnOceanSerialTransceiver RX thread started
==> /var/log/openhab/events.log <==
2023-05-29 09:53:19.300 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'enocean:bridge:FT3OLRGB' changed from OFFLINE (CONFIGURATION_PENDING): opening serial port... to OFFLINE (CONFIGURATION_PENDING): starting rx thread...
==> /var/log/openhab/openhab.log <==
2023-05-29 09:53:19.301 [INFO ] [nternal.handler.EnOceanBridgeHandler] - EnOceanSerialTransceiver RX thread up and running
==> /var/log/openhab/events.log <==
2023-05-29 09:53:19.304 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'enocean:bridge:FT3OLRGB' changed from OFFLINE (CONFIGURATION_PENDING): starting rx thread... to OFFLINE (CONFIGURATION_PENDING): trying to get bridge base id...
The thing status does not change afterwards? Can you set log:set TRACE org.openhab.binding.enocean on the karaf console and disable/enable the thing again? You can revert that log setting by exchanging TRACE with DEFAULT.
