I followed your suggestions. Removed the devices. Configured the username / password in the binding en restarted OpenHAB and added the device again.
Same issue. I have attached the logging wil all logging of the Shelly Binding on TRACE level from the start of the OpenHAB proces.
openhab.log (328.4 KB)
did you install the californium bundle? there are some dependency issues
289 │ Active │ 80 │ 2.0.0 │ Californium (Cf) Core
290 │ Active │ 80 │ 2.0.0 │ Californium (Cf) Element Connector
291 │ Active │ 80 │ 2.0.0 │ Californium (Cf) OSGi
292 │ Active │ 80 │ 2.0.0 │ Scandium (Sc) Core
weird.
shelly binding also active and not running twice.
could you check permissions to the addon files?
The binding is running fine. I also have a shell rgbw2 device and a shelly1 switch device which were already present in my network. I removed these devices also and there are autodiscovered correctly where the channels were automatically restored.
The permissions are:
-rw-r----- 1 openhab openhab 391883 Feb 17 09:46 org.openhab.binding.shelly-3.3.0-SNAPSHOT.jar
These permissions should be sufficient (since this and another DEV binding are running almost flawlessly). To be complete. The OpenHAB process is running as user openhab
these are my permissions
-rwxrwxrw- 1
At least @igi reported a bug on TRV initialization (missing channel drfinition for sensors#mode), which I’ll fix at the weekend
I think my setup also suffers from this bug (regarding the logged exception which also points to sensors#mode . Thank you very much looking into this. When the new version is available i will test it and see if it results in an improvement for my setup.
I created a PR and will spend some time the upcoming week
Please create an Issue for each bug here (you could also create feature requests, but bugs have prio). Prefix the Issues with “[shelly]”
This release will not include support for Shelly Gen2 (Plus/Pro), this will be the next round
New DEV build with updated TRV support
Make sure to delete and rediscover your things. Maybe you need to adjust your item linkage (sensor#mode has been moved to control#mode)
New features are not yet finally tested, there might be issues (I post another update when done).
Cool markus7017.
Just updated the binding and reinstalled my TRV now.
The new values are now visable. 
How can I now e.g. enable the “boost”?
I want to have a virtual switch were I can switch on the boost or not.
Can I find a hint in the documentation
Hi Markus
A couple of months ago you did some fixes for the Shelly EM to “calculate” the PF as it was not available in the /status. This has been fixed in the latest firmware
If the PF is now available from the /status which value will be used? The calculated value or the published value?
Thanks
Mark
Hi,
I’m still working on TRV implementation. There is already a new build just a few minutes ago.
Boost mode will have 2 channels
control#boost - enables/disables boost mode (on/off)
control#boostTimer - number of minutes boost will be active once started
In addition you’ll see
control#mode - manual/automatic
control#targetTemp - Temp for auto temp mode
control#position - valve position
sensor#state - valve open/closed
control#profile - Index of active profile
I think this should cover the relevant use cases. I think the design is ok, now I’m working on implementation and it requires more testing that it looks from a first point of view. E.g. what happens if valve is in manual mode when activating boost mode.
One limitation: Currently the CoAP update doesn’t include the remaining boost time. Therefore this requires polling. I need to optimize this, because usually it will be an 1h interval, because the TRV is a battery device. We also openred a feature request to add those to the CoAP status to avoid frequent polling just for this purpose.
@markus7017. Great with “the control#boost - enables/disables boost mode (on/off)”. But as far as I understood the booster feature, it has a start and stop value. So enable is good, but with the enable it will not start itself. Please check the TRV UI and you will see how it works with (start and stop).
My focus is to start the booster and after the default value from 30min it should come back to automatic mode. This should be done via a virtuell switch in OH.
And were is the lastest version of the binding? Here I can only found the version from this morning: https://github.com/markus7017/myfiles/tree/master/shelly
@markus7017 Thank you very much for this new version. After the things were deleted i could include them without any problems. The channels to control as well temperature as valve position works as expected and also batterylevel works perfect.
Thanks again and keep up the good work!
@markus7017, your latest version from this morning, works now like perfect. The booster feature is now able to switch on/off the TRV-booster-feature and starts. TRV is directly reacting from the automatic mode to the booster mode and back.
Many thanks for your excellent development here.
A question about these TRVs. Is it possible to use an external temperature sensor?
Yes, the Shelly HT is the right sensor for doing this. Current the supporting SW for the HT has an bug. But this should be solved soon.
I updated the DEV build to complete TRV support
Please help testuing so I could prepare the PR.