Thanks, recreating thing helped.
Hi Markus.
On v4.0.1 I get the following error messages during a restart (binding release build):
2023-07-30 18:12:30.557 [WARN ] [core.thing.internal.ThingManagerImpl] - Channel types or config descriptions for thing 'shelly:shellytrv:60a423dcc376' are missing in the respective registry for more than 120s. In case it does not happen immediately after an upgrade, it should be fixed in the binding.
2023-07-30 18:12:30.562 [WARN ] [core.thing.internal.ThingManagerImpl] - Failed to normalize configuration for thing 'shelly:shellytrv:60a423dcc376': {thing/channel=Type description shelly:deviceSchedule for shelly:shellytrv:60a423dcc376:device#schedule not found, although we checked the presence before.}
not sure what it means. Just wanted to bring this to your attention.
never seen something like this, try delete + re-discover the thing
Debug mode in OH I assume?
I Updated OH to the latest version and it’s happening, for my both Shelly devices. My OH3.x setup is still acting fine.
check thing config and disable CoIoT. In that case the binding only polls, in your case every 5min
I updated the DEV build
- Auth with Plus/Pro devices fixed, now implementing RFC-based ohandling with http header attributes rather making auth part of the RPC message @DUSAG0211
- various channel definitions have change, incl. device innerTemp, sensor temp, humidity, external sensor temp (add-on), relay voltage, current, supplyVoltage, currentWatts, lastPower1, accumulated*; please verify that units are correct and values are updated correctly. I’m using system: defined types rather than own definitions. Not for all channels, this requires refactoring of code and may break backward compatibility.
You might need to delete and re-discover things, but first try it with the existing definitions. - Processing for Soap value boost was missing, now updating the boost channel. I still need to check the TRV targetTemp topic
@Spaceman_Spiff Did you created the DEBUG log?
@Andy_Co This version def. has the vibration channel for motion, you might need to delete and re-discover your thing
@mr.airworthy Please check the update, maybe this was related to the channel definitions
@scheuerer This should fix HT humidity
Again, I kindly request you to support testing. Most of those issues could have been fixed before the 4.0 release. It’s hard to test The binding is supporting about 40 different devices, this make it hard to test all different configurations even @igi is doing a great job here.
3.4.5-DEV Gen1/Plus/Pro | 4.1.0-DEV Gen1/Plus/Pro | README | READMEbeta
Avdanced Users - Shelly Manager - Bugs/Features - API Doc | Firmware Index - Firmware Archive
Note: The DEV build is always newer than the version in the official Distro or Milestone builds
2 Likes
I restarted openHAB two times with DEBUG log enabled but this time all channels were created properly. 
I’ll try to remember to switch to DEBUG before every restart so in case creation fails I have the log set accordingly
Sorry Markus, it seems my problem with number:energy against number:power are not fixed in the latest DEV Binding from yesterday. When generating a new item still the wrong unit.
The same for humidity. I have had to delete the old item and create a new one that works.
In principal I have took my exisiting 4.0.1 system, deleted the binding, install the DEV binding, and restore my taken backup from the OH 3.4.4-1 system.
Any idea?
PS: This is the bundl list extract
269 │ Active │ 80 │ 4.1.0.202308010617 │ openHAB Add-ons :: Bundles :: Shelly Binding Gen1+2
Looks good to me. So far no issues anymore! Thanks!
you. wed to delete the thing, not the items; OH will restores the linkage when thing is rediscovered
Thanks, this works now.
But I’m not sure if it is an Shelly-Binding issue or it is a gerneal OH issue.
In general the “TYPE” for the item itself with humidity is missing.
E.g. Temperature is there, but no humidity.
Did you tried the new DEV build, works fine for me and @igi
There is no dedicated humidity type (for whatever reason). It uses Number:Dimensionless (0…100%).
@all please test the new build, I need feedback
Yes I used the DEV build.
It would be very easy for us, to have by default the humidity as on own type, like temperature,
or why we have for temperature one, because those a also only values between - and + .
Nope, the binding now uses system:atmospheric-humidity, which is pre-defined. I think you need to delete and re-discover the thin
No, this is absolutely wrong, as a temperature can be measured in Farenheit or Celsius. Therefore the specific number types exist, to simplify changes between one measurement to another. This does not apply for humidity, as this is just a percentage and therefore dimensionless.
Hans-Jörg. Yes you are right. But as said, the other thing is comfort. But this thing is crying on highest level. Basic things need to work first in OH4 and migration.
Btw, does anybody know why there is an item type
Number
and
Number:Dimensionless?
Sorry, don’t get you. What do you mean ?
I think he means that even though it makes sense to not add “humidity”, from an UX perspective having it there makes sense. An end user looking at the list will see:
“Temperature”
“Watts”
Etc
And will ask themselves “where is humidity??”. The fact that we need to explain that “humidity uses % and that’s equal everywhere so it doesn’t make sense to add” means that the UX decision of not putting humidity there was in fact wrong. Because you have to explain. Good UX should not require an explanation (heh… I have many personal opinions on this but…), it should create a seamless and meaningful experience between the application and the user, and not having the humidity unit there, breaks that experience (you’ll have users asking themselves “okay where or how do I add a % there?” And then it’s off to google to find.).
(At least that’s what I understood from the conversation, and even though I respect the decision, I’m inclined to agree that adding humidity there, even if redundant, would help new people. If for nothing else, because it helps those who need it most. It’s the little things 
)
@scheuerer please correct me if I’m wrong.
Missing Number:Humidity is not an UI decision, it is a technical design decision.
Imagine how many different value types are delivered as percentage ? Do you want to see them all in the list ? (Don’t expect an answer on this one)