Another “new” build? Behind the same link you’ve shared yesterday?
yes, it‘s always the same link
hi Markus
Thanks for the quick reply.
It is clear to me that I need the number itself, but with the item from the binding I get the value including% the sign.
with itemsValue do I only get the value of the item without any additions (like% characters) or do I get something wrong?
The value in the PaperUI is also 100%
I want the number to be pure, but I don’t think I can do that with itemValue.
Thx for the tip, i’ll iclude this in the code that way. (it is just a Quick an Dirty Try)
i tried the same as i did for the RF_Signal_item
<widget-icon iconset="'eclipse-smarthome-classic'" icon="'batterylevel-<Battery_item>'" size="25" /></span></div>
But its also not working
My HTML/CSS is limited too, but i learn every time I code something…or copy it
If you want the pure number with out the % just remove form your item the :Dimensionless
hey nikos
Thx, i’ve tried, but now i have NULL
Clear Cache and reload didn’t help as well
Edit: Restart OH helped now i got 100.0
ist there an easy and elegant code that convert the float number to a interger…
so that i get 100 instead of 100.0
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.
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
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
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)