Try to format your itemvalue like this | number:0
Great a big step closer 
now the output is 100 but how i get it together with the icon tag?
this isn’t the right way…
icon="'battery-itemValue(config.Battery_item)| number:0}}'"
or
icon="'battery-<itemValue(config.Battery_item)| number:0}}>'"
like this?
icon="'qualityofservice-<RF_Signal_item>'"
This notation works, but i didn’t see that in the doc…
i got the tip from markus
but may my english is bad or i blind, but i didn’t read it in the docs 
i do understand that you are annoyed by a newbie, but i think one purpose of the forum is to help new members if they don’t understand something right?
No, I’m not annoyed. I wanted to show you the right direction without doing it for you, because that would reduce your possibilities to learn and find it yourself the next time. 
And another point is, this thread is about shelly binding and not item configuration in general. I don’t know your native language, but IMO Google translate does a pretty good job to translate from/to English. For other language translations e.g. French/Russian the result is worse.
Just read the paragraph about dynamic icons.
So there’s no need to specify the value in the icons name, that’s already done by openHAB.
1 Like
All right, thanks for your understanding.
The questions come from the original question, so it ended up here. I have read the section a few times, but unfortunately I am lacking a concrete example of how to use an itemValue to call up the correct image.
saw some widgets that they were solved as I originally had it, namely with if itemValue == xy then icon XY and so on.
That’s why I think markus’ notation is so good, but I didn’t understand how I could get it directly with itemValue. The <RF_Signal_item> already has the correct format, unfortunately not for the battery, which is why I have to adjust it first.
<name>-<state>.<extension>
so how the
<state>
is written with itemValue() | number:0 adjustment… cus this is not right
icon="'batterylevel-{{itemValue(config.Battery_item)| number:0}}'"
its a Syntax Problem, not i Item problem in general
you know what i mean?
Many thanks, Markus! I did some test again with the recent build.
Now the log includes some definite messages regarding LONG_PRESSED
see:
2020-05-05 19:05:57.958 [TRACE] [elly.internal.coap.ShellyCoapHandler] - shelly1-pir: Sensor value[1]: id=118, Value=2.0 (Input, Type=S, Range=0(off)/1(on)/2(longpush), Link=0: Relay0)
2020-05-05 19:05:57.962 [TRACE] [elly.internal.coap.ShellyCoapHandler] - shelly1-pir: Coap update for button, typemomentary
2020-05-05 19:05:57.966 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shelly1-pir: Update button state with LONG_PRESSED
And with the “Don’t activate … long pushed.” set to enabled:
2020-05-05 19:12:29.426 [TRACE] [elly.internal.coap.ShellyCoapHandler] - shelly1-pir: Sensor value[1]: id=118, Value=2.0 (Input, Type=S, Range=0(off)/1(on)/2(longpush), Link=0: Relay0)
2020-05-05 19:12:29.430 [TRACE] [elly.internal.coap.ShellyCoapHandler] - shelly1-pir: Coap update for button (type momentary)
2020-05-05 19:12:29.433 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shelly1-pir: Update button state with LONG_PRESSED
So in both cases: The LONG_PRESSED events are noticed by the binding.
But the trigger event seem still not been issued.
The trigger event is not shown in the log and my test rule
rule "Tasterevent bearbeiten"
when
Channel "shelly:shelly1:pir:relay#button" triggered LONG_PRESSED
then
logInfo("SHELLY-PIR", "LONG_PRESSED Event erkannt")
end
… does not start.
When filtering for “LONG_PRESSED” the only lines matching are the two [DEBUG] lines shown above already but no channel trigger:
2020-05-05 19:05:57.966 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shelly1-pir: Update button state with LONG_PRESSED
2020-05-05 19:12:29.433 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shelly1-pir: Update button state with LONG_PRESSED
I added a fix, try latest build an
rule "long pressed"
when
Channel "shelly:shelly1:xxxxx:relay#button" triggered
then
var actionName = receivedEvent.getEvent()
switch(actionName) {
case "LONG_PRESSED": {
logInfo("test","long pressed")
...
}
case "LONG_RELEASED": {
logInfo("test","long released")
...
}
case "SHORT_PRESSED": {
...
}
case "DOUBLE_PRESSED": {
...
}
}
end
replace xxxxx with the correct id
Channel “shelly:shelly1:xxxxx:relay#button” triggered LONG_PRESSED
should also work
1 Like
You made my day, dude!
The LONG_PRESSED events are back 
I did a short test this morning and can confirm, that at least the SHORT_PRESSED and LONG_PRESSED events are issued:
2020-05-06 08:02:59.933 [INFO ] [se.smarthome.model.script.SHELLY-PIR] - SHORT_PRESSED erkannt
2020-05-06 08:02:59.940 [vent.ChannelTriggeredEvent] - shelly:shelly1:pir:relay#button triggered SHORT_PRESSED
2020-05-06 08:03:31.929 [vent.ChannelTriggeredEvent] - shelly:shelly1:pir:relay#button triggered SHORT_PRESSED
2020-05-06 08:03:31.940 [INFO ] [se.smarthome.model.script.SHELLY-PIR] - SHORT_PRESSED erkannt
2020-05-06 08:03:33.924 [vent.ChannelTriggeredEvent] - shelly:shelly1:pir:relay#button triggered LONG_PRESSED
2020-05-06 08:03:33.935 [INFO ] [se.smarthome.model.script.SHELLY-PIR] - LONG_PRESSED erkannt
2020-05-06 08:03:40.950 [vent.ChannelTriggeredEvent] - shelly:shelly1:pir:relay#button triggered SHORT_PRESSED
2020-05-06 08:03:40.960 [INFO ] [se.smarthome.model.script.SHELLY-PIR] - SHORT_PRESSED erkannt
2020-05-06 08:03:42.885 [vent.ChannelTriggeredEvent] - shelly:shelly1:pir:relay#button triggered LONG_PRESSED
2020-05-06 08:03:42.894 [INFO ] [se.smarthome.model.script.SHELLY-PIR] - LONG_PRESSED erkannt
2020-05-06 08:04:14.283 [vent.ChannelTriggeredEvent] - shelly:shelly1:pir:relay#button triggered SHORT_PRESSED
2020-05-06 08:04:14.295 [INFO ] [se.smarthome.model.script.SHELLY-PIR] - SHORT_PRESSED erkannt
2020-05-06 08:04:14.981 [vent.ChannelTriggeredEvent] - shelly:shelly1:pir:relay#button triggered SHORT_PRESSED
2020-05-06 08:04:14.991 [INFO ] [se.smarthome.model.script.SHELLY-PIR] - SHORT_PRESSED erkannt
Though, I’m not able to get DOUBLE_PRESSED nor LONG_RELEASED events (yet).
For the sake of completeness, this is the current test rule:
rule "Tasterevent bearbeiten"
when
Channel "shelly:shelly1:pir:relay#button" triggered
then
var actionName = receivedEvent.getEvent()
switch(actionName) {
case "LONG_PRESSED": {
logInfo("SHELLY-PIR","LONG_PRESSED erkannt")
}
case "LONG_RELEASED": {
logInfo("SHELLY-PIR","LONG_RELEASED erkannt")
}
case "SHORT_PRESSED": {
logInfo("SHELLY-PIR","SHORT_PRESSED erkannt")
}
case "DOUBLE_PRESSED": {
logInfo("SHELLY-PIR","DOUBLE_PRESSED erkannt")
}
}
end
For testing I reconfigured the button config of that particular Shelly to “Detached” just to find out if this brings the DOUBLE_PRESSED and LONG_RELEASED events:
But even when in “Detached Button mode” these events are not there.
BTW: Is the DOUBLE_PRESS sent by the Shelly or is this derived from subsequent on/off events by the bindings logic? Just curious
Anyway, it’s worth definitely having this since this might come handy for some use cases. So thanks for working on this too!
To be clear, I’m not in need for the DOUBLE_PRESS and LONG_RELEASED for now. But when you’re implementing these, I’m happy to test to help improving the Shelly integration into openHAB.
AND: Once it’s working, this adds more possibilities again and new ideas will come for sure
those are not available for Coap. As you see it reports 0=release, 1=short, 2=long
the event needs to be generated by the device, there is no logic by on/off in the binding
O.k. understood: Not available via Coap.
So currently these events should be available via http only because they haven’t been added to CoIoT by Alterco yet? Probably this might change with 1.7?
1.7rc1 is available, but doesn’t include CoAP enhancements
fyi: PR 7563 was merged with some bug fixes
- [shelly] Support short/long pressed CoAP events #7558
- [shelly] AutoCoIOT does not work in new installations #7559
- [shelly] Resolve hostname to IP address #7560
offiecial SNAPSHOT build can be found here
1 Like
I’m integrating Shelly Vintage, who has one and could support with testing?
DEV Build could be found here (this is newer than the official SNAPSHOT mentioned above)
Hi Markus,
new toy - new questions
I just got a couple of Shelly-DW’s and trying them to integrate into openHAB. Inclusion and firmware update went well. Now the sensors are on
Firmware: v1.6.5
Binding version is a quite recent jar (5th of May):
12 x Active x 80 x 2.5.5.202005052017 x openHAB Add-ons :: Bundles :: Shelly Binding
When the DW first got in touch with Shelly binding, I woke them up to let the binding initialize.
Basically, the DW sensor works: It reports OPEN/CLOSED and vibration and after some time the battery level. But some other values (wakeupReason, lastError, lastUpdate, uptime, wifiSignal) are missing.
Are they not available via Coap? What am I doing wrong?
Here is the thing:
Thing shelly:shellydw:tuer "Eingangstür" @ "somewhere" [ deviceIp="192.168.9.17", eventsCoIoT=true ]
and the items:
Group gShellyTuer
Contact ShellyTuer "Eingangstür [%s]" (gShellyTuer, gMapdb) {channel="shelly:shellydw:tuer:sensors#state" }
Switch ShellyTuer_vibration "Erschütterung" (gShellyTuer) {channel="shelly:shellydw:tuer:sensors#vibration" }
String ShellyTuer_reason "Aufwachgrund [%s]" (gShellyTuer) {channel="shelly:shellydw:tuer:sensors#wakeupReason" }
DateTime ShellyTuer_last "Lebenszeichen [%1$ta, %1$te. %1$tb %1$tk:%1$tM]" (gShellyTuer) {channel="shelly:shellydw:tuer:sensors#lastUpdate" }
String ShellyTuer_error "Letzter Fehler [%s]" (gShellyTuer) {channel="shelly:shellydw:tuer:sensors#lastError" }
Number ShellyTuer_batt "Batterie" (gShellyTuer) {channel="shelly:shellydw:tuer:battery#batteryLevel" }
Number ShellyTuer_uptime "Laufzeit [%d s]" <clock_grey> (gShellyTuer) {channel="shelly:shellydw:tuer:device#uptime"}
Number ShellyTuer_rssi "Signalstärke [%d]" <wifi> (gShellyTuer) {channel="shelly:shellydw:tuer:device#wifiSignal"}
This is the log from some OPEN/CLOSED cycles:
2020-05-10 11:00:27.216 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shellydw-fa902a: CoIoT Message from /192.168.9.17:5683 (MID=25801): {"G":[[0,66,200],[0,55,1],[0,77,98],[0,88,-1],[0,99,0]]}
2020-05-10 11:00:27.220 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shellydw-fa902a: Duplicate serial 256 will be processed, because payload is different: {"G":[[0,66,200],[0,55,1],[0,77,98],[0,88,-1],[0,99,0]]} vs. {"G":[[0,66,164],[0,55,0],[0,77,98],[0,88,-1],[0,99,0]]}
2020-05-10 11:00:27.225 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shellydw-fa902a: CoIoT Sensor data {"G":[[0,66,200],[0,55,1],[0,77,98],[0,88,-1],[0,99,0]]}
2020-05-10 11:00:27.230 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shellydw-fa902a: 5 CoAP sensor updates received
2020-05-10 11:00:27.256 [DEBUG] [lly.internal.util.ShellyChannelCache] - shellydw-fa902a: Channel sensors#state updated with OPEN (type class org.eclipse.smarthome.core.library.types.OpenClosedType).
2020-05-10 11:00:27.272 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shellydw-fa902a: 1 channels updated from CoIoT status
2020-05-10 11:02:48.229 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shellydw-fa902a: CoIoT Message from /192.168.9.17:5683 (MID=34478): {"G":[[0,66,280],[0,55,0],[0,77,98],[0,88,-1],[0,99,0]]}
2020-05-10 11:02:48.233 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shellydw-fa902a: Duplicate serial 256 will be processed, because payload is different: {"G":[[0,66,280],[0,55,0],[0,77,98],[0,88,-1],[0,99,0]]} vs. {"G":[[0,66,200],[0,55,1],[0,77,98],[0,88,-1],[0,99,0]]}
2020-05-10 11:02:48.236 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shellydw-fa902a: CoIoT Sensor data {"G":[[0,66,280],[0,55,0],[0,77,98],[0,88,-1],[0,99,0]]}
2020-05-10 11:02:48.240 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shellydw-fa902a: 5 CoAP sensor updates received
2020-05-10 11:02:48.251 [DEBUG] [lly.internal.util.ShellyChannelCache] - shellydw-fa902a: Channel sensors#state updated with CLOSED (type class org.eclipse.smarthome.core.library.types.OpenClosedType).
2020-05-10 11:02:48.256 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shellydw-fa902a: 1 channels updated from CoIoT status
2020-05-10 11:03:52.740 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shellydw-fa902a: CoIoT Message from /192.168.9.17:5683 (MID=40787): {"G":[[0,66,319],[0,55,0],[0,77,98],[0,88,-1],[0,99,1]]}
2020-05-10 11:03:52.744 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shellydw-fa902a: Duplicate serial 256 will be processed, because payload is different: {"G":[[0,66,319],[0,55,0],[0,77,98],[0,88,-1],[0,99,1]]} vs. {"G":[[0,66,280],[0,55,0],[0,77,98],[0,88,-1],[0,99,0]]}
2020-05-10 11:03:52.747 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shellydw-fa902a: CoIoT Sensor data {"G":[[0,66,319],[0,55,0],[0,77,98],[0,88,-1],[0,99,1]]}
2020-05-10 11:03:52.751 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shellydw-fa902a: 5 CoAP sensor updates received
2020-05-10 11:03:52.780 [DEBUG] [lly.internal.util.ShellyChannelCache] - shellydw-fa902a: Channel sensors#vibration updated with ON (type class org.eclipse.smarthome.core.library.types.OnOffType).
2020-05-10 11:03:52.789 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shellydw-fa902a: 1 channels updated from CoIoT status
2020-05-10 11:04:13.259 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shellydw-fa902a: CoIoT Message from /192.168.9.17:5683 (MID=5104): {"G":[[0,66,212],[0,55,0],[0,77,98],[0,88,-1],[0,99,1]]}
2020-05-10 11:04:13.266 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shellydw-fa902a: Duplicate serial 256 will be processed, because payload is different: {"G":[[0,66,212],[0,55,0],[0,77,98],[0,88,-1],[0,99,1]]} vs. {"G":[[0,66,319],[0,55,0],[0,77,98],[0,88,-1],[0,99,1]]}
2020-05-10 11:04:13.272 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shellydw-fa902a: CoIoT Sensor data {"G":[[0,66,212],[0,55,0],[0,77,98],[0,88,-1],[0,99,1]]}
2020-05-10 11:04:13.278 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shellydw-fa902a: 5 CoAP sensor updates received
2020-05-10 11:05:14.027 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shellydw-fa902a: CoIoT Message from /192.168.9.17:5683 (MID=27756): {"G":[[0,66,296],[0,55,1],[0,77,98],[0,88,-1],[0,99,0]]}
2020-05-10 11:05:14.031 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shellydw-fa902a: Duplicate serial 256 will be processed, because payload is different: {"G":[[0,66,296],[0,55,1],[0,77,98],[0,88,-1],[0,99,0]]} vs. {"G":[[0,66,212],[0,55,0],[0,77,98],[0,88,-1],[0,99,1]]}
2020-05-10 11:05:14.034 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shellydw-fa902a: CoIoT Sensor data {"G":[[0,66,296],[0,55,1],[0,77,98],[0,88,-1],[0,99,0]]}
2020-05-10 11:05:14.038 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shellydw-fa902a: 5 CoAP sensor updates received
2020-05-10 11:05:14.051 [DEBUG] [lly.internal.util.ShellyChannelCache] - shellydw-fa902a: Channel sensors#state updated with OPEN (type class org.eclipse.smarthome.core.library.types.OpenClosedType).
2020-05-10 11:05:14.064 [DEBUG] [lly.internal.util.ShellyChannelCache] - shellydw-fa902a: Channel sensors#vibration updated with OFF (type class org.eclipse.smarthome.core.library.types.OnOffType).
2020-05-10 11:05:14.071 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shellydw-fa902a: 2 channels updated from CoIoT status
Any thoughts?
Hello,
i tried your rule to get the things status when they change,
the problem I am facing is that the shelly plug thing updates from unkown to online but doesn’t update from online to unknown in case i unplug any of the shellys,
I tried configuring through Paper UI and through .things file but as you can see in the screenshot the binding keeps showing the devices as always online unless i restart.
Plz let me know what can i provide to be able to trace the issue,
2020-05-10 20:25:08.884 [vent.ItemStateChangedEvent] - CPU_Uptime changed from 37.8 to 40.4
==> /var/log/openhab2/openhab.log <==
2020-05-10 20:27:44.760 [WARN ] [y.internal.handler.ShellyBaseHandler] - shellyplug-7bcca9: Event triggered: RESTARTED
==> /var/log/openhab2/events.log <==
2020-05-10 20:27:44.780 [vent.ChannelTriggeredEvent] - shelly:shellyplug:7bcca9:device#alarm triggered RESTARTED
2020-05-10 20:27:44.819 [me.event.ThingUpdatedEvent] - Thing 'shelly:shellyplug:7bcca9' has been updated.
2020-05-10 20:27:48.989 [vent.ItemStateChangedEvent] - CPU_Uptime changed from 40.4 to 43.1
2020-05-10 20:27:49.004 [vent.ItemStateChangedEvent] - Network_DataSent changed from 12 to 13
2020-05-10 20:27:49.253 [vent.ItemStateChangedEvent] - Sensor_CPUTemp changed from 34.3 to 34.9
2020-05-10 20:28:07.357 [me.event.ThingUpdatedEvent] - Thing 'shelly:shellyplug:7bcca9' has been updated.
2020-05-10 20:28:38.325 [vent.ItemStateChangedEvent] - Hotwater_RSSI changed from 66 to 64
2020-05-10 20:28:38.335 [vent.ItemStateChangedEvent] - Hotwater_Uptime changed from 0T00:30:11 to 0T00:35:11```
at 20:28 i unplugged the shelly and it still shows online
thanks,
The binding will not set the thing back to unknown, just offline - communication error.
Unknown can only be set at a restart.
it doesn’t even set it to offline, i just stays online that’s what i was trying to relay
I uninstalled the binding, restarted , reconfigured the shelly plug and still the thing state doesn’t go into offline mode. P.S Unknown was set at restart and Online sets up also only offline doesn’t show… can i help with a trace or something plz let me know,
thanks again,