Thanks
adding [%1$td.%1$tm.%1$ty / %1$tH:%1$tM:%1$tS] helps to display DateTime in sitemaps.
1 Like
We are closing the release, is there anything, which was not discussed here, but causes a problem?
Today I included CoAP-based power/brightness/state-Updates for RGBW2 in White Mode and fixed ON/OFF.
We do final zesting tomorrow, then the PR gets closed and we have a stable release. Further development will be managed in a new PR.
Hi, we are facing the target line for the release. I already have some good feedback. Now Iâm looking for some early adaptors. This build provides the full feature set and bugfixes. Beside supporting new devices (EM3, DW, Smoke, 1/1PM Addon) the focus on this release is a way better CoIoT/CoAP support, which will provide faster status updates. An upgrade for firmware 1.6+ is strongly recommended to utilize these benefits.
Please make sure to delete all things and re-discover them. OH usually restores the Channel/Item linkage. Nevertheless, a backup is always a good idea 
The are changes to the channel layout, e.g. RGBW2. For most devices you will find only additional channels, but RGBW2-white has a significant new layout, which could require you to refine your item definitions (usually not a big thing), e.g. Power+Brightness now map to the same channel in white mode. Check the updated README for more details.
Looking forward to your feedback.
1 Like
ok, one more update for the Door Window: tilt and vibration are now reported via CoAP when you use firmware 1.6.5. On the other side I corrected the item type for tilt, which caused an exception when adding the sensor channels. Both shoild be fixed. @nikos7179 is verifying this.
IMPORTANT UPDATE @nikos7179 and me figured out the problem. Firmware 1.6.5 reports the tilt status as int and not as bool as described in the documentation. This caused the JSON parser to throw an exception. Unfortunately this was not shown in the log.
I fixed the variable type and implemented the new sensor urls open_url and vibration_url (when not in CoIoT mode). Iâm not sure if this change interferes with older firmware releases, so you might need to upgrade to 1.6.5. This will also speed up the reporting of tilt and vibration status, because they are now provided by CoIoT too. And last, but not least I had a typo in the channel name for tilt (and not title 
)
The PR is facing the final stage. Maybe I got it merged for release 2.5.4.
Please support with final testing. Itâs essential to have a stable release.
1 Like
I have been testing RGBW2 in latest DEV release.
Now showing single INPUT and POWER channel for each device as expected 
Each relay now only has BRIGHTNESS channel (accepts ON/OFF and Numerical Value commands). Needed to update all my items that linked to âPOWERâ channel.
Updates from input and power are very quick (i have enabled CoIoT on each device).
Thanks for fixing the ON/OFF command issue in the previous release Markus
Does someone has a DW with firmware < 1.6.5?
Ding Dong - we are reaching 2.5.4 pre-final
I updated the DEV build with the latest changes from the review process, but also 1 significant feature: AutoCoIot-optimized updates reducing REST polls and system load.
As you might now firmware 1.6 brought significant updates to the CoAP events, which makes it now the binding default. The Action URLs are still supported, but it turned out they active URLs higher the chance of API timeouts, because the device is lacking resources while triggering the Action URL. In addition a http clallback consumes more energy than just sending a CoAP UDP packet (at least in theory that helps to improve battery life).
The binding now enables CoIoT events by default and disables the Action URLs. Those will also be disabled when the device is available for a REST call at thing initialization (sensors might be in sleep mode). This feature requires firmware 1.6 or newer. The automatism could be disabled in the binding configuration. Then you are able to control the event types in the thing configuration.
This is also used to optimize REST polling. Previous versions did a extra REST poll after a CoAP update was processed to fill the missing channels. In beetween CoAP includes all releavant status information so REST polls can be skipped for Lights (Bulb, Duo, RGBW2) and Sensors. For now the binding keeps those polls for relay devices. Maybe firmware 1.7 will abllow to disable them completely. Again this feature depends on Aito-CoIoT = firmware 1.6+ has to be on the device.
Beside that the new release has a lot to offer:
- New devices are supported: Duo, EM3, Door Window; Smoke fixed
- Support for external temp/humidity sensors when the Addon for 1/1PM is installed
- Significant improvement of CoIoT updates. Firmware 1.6 brought a lot of required changes. Firmware 1.7 will complete them, we are working with Alterco
- CoIoT events are activated automatically when firmware 1.6 or newer is detected. Youâll notice near-realtime updates of input/output/meter values etc. Auto-enabling CoIoT can be disabled in the binding config.
- Sensors get ONLINE if only CoIoT is enabled (older version require also the Sensor Report Event)
- RGBW2 now provides aggregated meter values rather than per channel - that seems to be more useful
- Various channels are now created dynamically. This simplifies adaption to different device types, e.g. if you install the 1/1PM Addon with a temp sensor the channel gets created when the device initializes next time.
- Action URLs are set or cleared depending on the Thing Configuration (and Auto-CoIoT binding config)
- Action URLs for Roller, DW and Flood events added
- You could set the default userid + password in the binding config. This makes it easier to discover a bigger number of password protected devices on the network sharing the same credentials. Set this option before you start discovery (or delete the thing and re-discover)
- HTTP API access has been reworked and improved. Now the binding does 3 retries on timeout errors.
- Things auto-initialize when they become online, trigger an action URL or send a CoAP message.
- The number of digits are reduced fpr Watt values etc. to prevent channel updates and log entries for âmicro-changesâ (0.002W etc.)
- Localization: All WARNING and INFO messages are now localized, missing localizations added
- Log optimizations
- every thing specific messages has the thing-id as prefix. This allows easy filtering of a single device just by using grep.
- various log entries are refined to make them more expressive have been removed
and more.
Changes breaking backward compatibility:
- RGBW2: Please note that this release uses a different channel structure, you need to re-link channels or update .things definitions, see README
- RGBW2 in white mode merged the power and brightness channels. You could link both items (Switch + Number) to the brightness channel - see README
- fyi: With the next release also the RGBW2 color mode will merge on/off and gain so the standard UI control can be used to control the gain rather brightness.
The updated binding jar could be found here: https://github.com/markus7017/myfiles/blob/master/shelly/org.openhab.binding.shelly-2.5.4-SNAPSHOT.jar?raw=true
together with the updated README
I highly appreciate if you could give it a try so I get positive feedback or the cache to fix something before the PR is merged. I expered the code merge this weekend.
2 Likes
Hi Markus,
I have just had a try with the new one.
The binding now enables CoIoT events by default and disables the Action URLs.
On the contrary, I noticed that the Action URLs still get enabled upon startup:
2020-04-19 09:33:27.768 [INFO ] [y.internal.handler.ShellyBaseHandler] - shelly1 - INFO: Firmware v1.6 or never was detected, enabling CoIoT events by default.
2020-04-19 09:33:27.769 [TRACE] [ng.shelly.internal.api.ShellyHttpApi] - shelly1: HTTP GET for http://192.168.42.61/settings/relay/0?out_on_url=http%3A%2F%2F192.168.42.236%3A8080%2Fshelly%2Fevent%2Fshelly1-8b18a1%2Frelay%2F0%3Ftype%3Dout_on
hmm, I canât confirm. I testet
- Auto-CoIoT true in binding config
- Default thing config as well as having Switch events and CoIoT events on in thing config
- URLs were null â remain null
- URL point to other device â stays as is
- URL points to this OH â will be cleared (null)
Are you sure you are using the correct DEV build? (do not use the version installable by PaperUI)
Is your system running on 192.168.42.236?
The PR has been merged yesterday evening so this is the official SNAPSHOT build, please try this one:
https://openhab.jfrog.io/openhab/libs-pullrequest-local/org/openhab/addons/bundles/org.openhab.binding.shelly/2.5.4-SNAPSHOT/org.openhab.binding.shelly-2.5.4-SNAPSHOT.jar?raw?true
I used the link in your announcement post - which gave me 2.5.4.202004180813 while the one in your reply gives 2.5.4.202004191013.
Is your system running on 192.168.42.236?
Yes, thatâs my test OH.
The PR has been merged yesterday evening so this is the official SNAPSHOT build, please try this one:
JFrog
I gave a try to the one you just linked (2.5.4.202004191013). It does (almost) the same:
2020-04-19 14:11:19.755 [DEBUG] [y.internal.handler.ShellyBaseHandler] - shelly1: Start initializing thing shelly test, type shelly1, ip address 192.168.42.61, CoIoT: true
âŠ
2020-04-19 14:11:20.072 [DEBUG] [y.internal.handler.ShellyBaseHandler] - shelly1: Initializing device shelly1-8b18a1, type SHSW-1, Hardware: Rev: prod-2018-08, batch 2; Firmware: v1.6.2 / 20200320-123430 (514044b4)
âŠ
2020-04-19 14:11:20.157 [TRACE] [ng.shelly.internal.api.ShellyHttpApi] - : HTTP GET for http://192.168.42.61/settings/relay/0?out_on_url=http%3A%2F%2F192.168.42.236%3A8080%2Fshelly%2Fevent%2Fshelly1-8b18a1%2Frelay%2F0%3Ftype%3Dout_on
âŠ
Do you see this message in the log âAuto-CoIoT is enabled, disabling action urlsâ
please share a screenshot from your binding and thing config->more#
Did you tried to delete and re-discover the things?
Do you see this message in the log âAuto-CoIoT is enabled, disabling action urlsâ
There are such messages in the log, but I canât identify which binding version dumped them.
The strange thing is, that for the recent startups there are no such messages in the log. Something is not consistentâŠ
openhab@bay:~$ grep "Auto-CoIoT" ~/openhab/userdata/logs/openhab.log
2020-04-19 09:07:05.020 [DEBUG] [y.internal.handler.ShellyBaseHandler] - shelly1-8b18a1: Auto-CoIoT is enabled, disabling http events
2020-04-19 13:50:34.377 [DEBUG] [y.internal.handler.ShellyBaseHandler] - shelly1-8b18a1: Auto-CoIoT is enabled, disabling action urls
2020-04-19 14:06:08.038 [DEBUG] [y.internal.handler.ShellyBaseHandler] - shelly1-8b18a1: Auto-CoIoT is enabled, disabling action urls
openhab@bay:~$
please share a screenshot from your binding and thing config->more#
Thing shelly:shelly1:8b18a1 "shelly test" @ "test" [deviceIp="192.168.42.61", eventsCoIoT=true]
open oh console and run
bundle:list | grep Shelly
check for multiple entries
The log shows that the message at 9:07 is some old binding version
maybe you need to run openhab-cli clean-cache, sometimes the jar ist not fully cleared from the cache
open oh console and run
bundle:list | grep Shelly
check for multiple entries
openhab> bundle:list | grep Shelly
244 x Active x 80 x 2.5.4.202004190943 x openHAB Add-ons :: Bundles :: Shelly Binding
openhab>
The log shows that the message at 9:07 is some old binding version
I made some effort to find out the message sourcesâŠ
That âoldâ is from 2.5.2.202003072040 which I had before todayâs experiments:
openhab@bay:~/openhab/tmp$ unzip -joq org.openhab.binding.shelly-2.5.2-SNAPSHOT.jar org/openhab/binding/shelly/internal/handler/ShellyBaseHandler.class ; procyon ShellyBaseHandler | grep Auto-CoIoT
this.logger.debug("{}: Auto-CoIoT is enabled, disabling http events", (Object)this.thingName);
The ones after 1PM must have come from 2.5.4.202004180813:
openhab@bay:~/openhab/tmp$ unzip -joq org.openhab.binding.shelly-2.5.4.202004180813.jar org/openhab/binding/shelly/internal/handler/ShellyBaseHandler.class ; procyon ShellyBaseHandler | grep Auto-CoIoT
this.logger.debug("{}: Auto-CoIoT is enabled, disabling action urls", (Object)this.thingName);
openhab@bay:~/openhab/tmp$
The " newest" one - 2.5.4.202004190943 do not have such message in the code:
openhab@bay:~/openhab/tmp$ unzip -joq org.openhab.binding.shelly-2.5.4.202004190943.jar org/openhab/binding/shelly/internal/handler/ShellyBaseHandler.class ; procyon ShellyBaseHandler | grep Auto-CoIoT
openhab@bay:~/openhab/tmp$
maybe you need to run openhab-cli clean-cache, sometimes the jar ist not fully cleared from the cache
I did clear the cache between version switchesâŠ
who else wants to do a test?
make sure to run the binding in DEBUG modr
I found yet another issue:
If the thing definition contains hostname and not IP address, the CoIoT updates sent by the shelly are not processed.
Is it a bug, or a (should be) known limitation?
I will not support this scenario. That would require a reverse lookup of the dns name
Donât exactly understand this pointâŠ
What I would expect is to translate the hostname to IP upon reading the .things file and use that IP. That does not need any reverse lookup.
That works fine in all other bindings I use (and with shelly too, except the CoIoT update processing).
@markus7017 : I just recieve my Shelly Vintage. I read you want people to test it. Actually I have only shelly 1 and 2. I have recieve Shelly plug S and 3 EM too.
Iâm using textual configuration but on github, There is no description to configure 3EM and Vintage âŠ
271 â Active â 80 â 2.5.4 â openHAB Add-ons :: Bundles :: Shelly Binding
Together with @englishman.hu we figured out what happens
- the issues is only relevant to existing installations getting updated by the new jar. In this case the current configuration is used
- the new versions brings an additional parameter in the binding config: autoCoIoT, default false
- Due to the fact that we made good experience with Coap and firmware 1.6+ I set the new default to true
- Howeber, this requires that the binding config is editred, something is changed and the config will be saved, otherwise the default doesnât become active
- To make this consistent I changed the default in the code to true, which means: if the parameter is missing in the (updated) config then default is true, which corresponds to the situation that the binding is newley installed
To bypass this with version 2.5.4
- go to the binding config
- make a change (change the default user, or add a dummy parameter)
- click save
the new config together with firmware 1.6 overrules the thing config.
or (IF you have firmware 1.6+ on the device):
- go to the config of each thing
- enable CoIoT events
- disable all others
in both cases thing gets re-initialized and you shouldnât the the Action URL set in the Web UI