@markus7017 would the Shelly Binding use and work with an additional (second) LAN interface in e.g. my IoT VLAN?
There is an update interval in the HTTP setting and it is set to 15, however I see updates as often as 2-3 seconds, so it seems this setting doesn’t affect ColoT events.
I’ll disable ColoT and see what happens.
Edit : disabled ColoT events in paper UI, I still get updates every few seconds.
Thanks for the quick reply,
Izhar
The binding gets the network interface address from OH‘s network config. I think this should be only relevant for building the action urls. Those are not used when CoIoT is enabled. Nevertheless, devices are discovered using mDNS, which only works on the local subnet. You could add the thing manually and give it a try.
did you switched off AutoCoIot in the binding config?
No, I didn’t.
it works now - Thanks.
@igi pointed me to a solution for that problem: OH has an integrated feature to filter the event log, see the discussion here
The configuration is added as a new section to
openhab2-userdata/etc/org.ops4j.pax.logging.cfg
Based on this you could use the following config:
# custom filtering rules
log4j2.appender.event.filter.uselessevents.type = RegexFilter
log4j2.appender.event.filter.uselessevents.regex = .*(heartBeat|LastUpdate|lastUpdate|LetzteAktualisierung|Uptime|Laufzeit|ZuletztGesehen).*
log4j2.appender.event.filter.uselessevents.onMatch = DENY
log4j2.appender.event.filter.uselessevents.onMisMatch = NEUTRAL
This filters events for items heartBeat, lastUpdate, LetzteAktualisierung, Uptime, Laufzeit, ZuletztGesehen. Replace those strings with the items you want to filter.
Please note: Once events are filtered they are “lost”, you can’t find them later.
I just installed several Shelly1 in my smart home and use them mostly in the Detached mode, to have the output alsways Ono, as the smart devices behind the switches are usually hue-lamps etc.
Unfortunately, I noticed that the delay when changing the input/pressing the switch to an update in openhab is quite long. I’m using CoIoT and you already mentioned 2-3 seconds for updates. This might be ok for other use-cases, but when switching on a lamp that feels quite broken.
Is there any way to speed up the updates? The other way from openhab to shelly is very fast, when sending a command. I’m already using Firmware v1.8 and the latest binding vom OH 2.5.9
please verify that firmware is 1.8.3+ This has a fix for CoAP performance, you should see response times of < 1sec.
Yes it’s v1.8.3@4a8bc427.
then I need a DEBUG log
I’m happy to provide that. Anything special I can filter for as I have over 100 things in openhab a full DEBUG of everything gets massively floated.
Also I have to correct myself: The delay seems to only happen on the Shelly 2.5, the Shelly 1 is pretty fast in execution. But also the 2.5 has the mentioned v1.8.3 firmware.
I have setup a second network connection to my IoT LAN (VLAN eth0.50) and tested it, while having my original (non VLAN) IP in the openhab config. The VLAN itself as a network interface worked (openhab web accessible etc.), but the shelly binding did not catch the mutlicast CoIoT packets from the VLAN connected devices (Shelly devices on my IoT WLAN connected to the VLAN). That was not really a surprise to me as openhab was configured to the (non VLAN) IP. I do not want and cannot run openhab in the (untrusted) IoT VLAN. As openhab is not able to bind to two IP addresses (or am I wrong?), this is no solution.
@markus7017 would it be possible to modify the shelly binding to listen for the multicast CoIoT communication on more than one network? Maybe on all networks configured on the openhab host? That would solve the problem.
Another solution I am trying as an alternative is to find a tiny multicast relay daemon to be run on the openhab system. That would send the CoIoT multicasts from the VLAN to the LAN. For security I then would use the second network (IoT VLAN) with iptables to not expose the whole openhab to my (untrusted) IoT VLAN.
Any help / comment / feedback welcome 
what I could do is to add an option to the binding config
default/empty: interface address from OH network config
if filled: use this address as local ip
Great idea. Please let me know when you need to test and please provide instructions to me how to.
Here is the first build for openHAB 3.0 (AFAIK they plan to publish first milestone during the next days)
Latest DEV build: 2.5.9 - 3.0.0 - README - Installation - Firmware Index - Firmware Archive - API Doc
@markus7017 will this DEV build run on 2.5.x? Have you included the network setting? If so, I will test 
No, oh3 bindings will not run on oh2.x
No worries, I’ll aos create a 2.5.x build for a while
I’m waiting for Shelly motion.
Will you integrate this in your binging? V2 and v3?