and you find another update with some fixes around the control#profile channel (use 0 to disable a profile and 1…5 to select a specific profile)
I posted a new DEV build
- polling during boost mode has been optimized/remove
Who could help to validate the TRV integration, valve state/pos, boost mode etc.?
I remember that somebody posted a problem with the vibration of DW2
on the other side I would like to confirm tilt updates.
Who has a DW2 and could run a tests that all sensor updates are processed correctly and channels get updated near-realtime (ca. 3sec delay for Wifi connect)?
Are there any other known problems with the binding? I would to get a stable status before moving to Plus/Pro integration.
Are there any binding news regarding the new PLUS and PRO series from Shelly?
New update
- Status updates while boost mode is active optimized
- Handling for DW2 status.sensor_error added (don’t fire alarm if sensor_error reports 0)
- Missing channel status LED added for Dimmer2
- log “channel updated with value xx” only if data has changed and channel is linked
- problems with data format while initializing a bulb fixed
Not when, this will start when Gen1 support is stabilized.
I already started to work on Plus/Pro but this will take a while.
2 Likes
New DEV build
- Dimmer1/Dimmer2: channel timerActive was missing
- Motion: Time for motionActive and motionTimestamp was 1h off
1 Like
Hi Markus,
not sure anymore if the following behaviour was different in earlier versions or I mix it up with shelly GUI.
When using oh-stepper for setting targetTemp each time I press „+“ the command is sent immediately to the TRV. It would be better if the binding could delay this command in case you press multiple times „+“. Otherwise you need to wait about 5 seconds until you can press „+“ again. This is how shelly GUI also works.
Nope, the binding will no buffer any commands, that’s a guarantee for problems. You could use the knob element
1 Like
I starting working on Plus/Pro support, but it will take a while. Discovery works already.
8 Likes
I have some issue with a HT which was added to OH3.2.0
The settings value “status interval” seem to be set to min. 60 sec.
In past I was able to set it to 10 or less sec as min. sample rate.
Pricipale it works, but the sample rate is to low some how, that OH 3.2 will not more get all values, every 10 min, when the HT sends the value. The HT is connected via USB to the power.
Here are some examples.
From the curve you can see that the sample rate is much lower compared to other HT’s…
Here are some examples:
It doesn’t make sense to change interval for H&T polling (or in general for all battery powered devices). There is no way to actively wake-up the device while in sleep mode. Allterco implemented some logic to optimized battery lifetime.
You need to have a clean setup of CoIoT notifications. Make sure that CoIoT is enabled you your OH IP is specified as peer address in the device settings. You could use Shelly Manager (oh ip:8080/shelly/manager). Press the H&T button to wake up the device before making changes.
Changes to the measurements will be updated instantly once the device sends them (also depending on selected treshholds).
Update on Shelly Plus/Pro integration - it’s coming.
- Device discovery has been implemented
- Most channels are already created based on available data
- Some channels are already filled with device data
- WebSocket connect for notifications is implemented, but status updates not yet
The objective is to have one binding supporting Gen1 and Plus+Pro devices. I think I have a beta for initial testing next week. @igi is already involved and will help on initial testing.
6 Likes
Thanks for the Feedback.
CoIoT was set before etc. The new HT was an old HT and everything were everywhere were set. beforehand.
I have now rebooted OH and now it seems, that the value come all 10min as before.
Thanks for the tip.
Hi
i tried to insert my plugs with file setup into my system… and the thing is green and marked as online bit the items are showing “invalid link”…
the thing (which is online)
Thing shelly:shellyplugs:SPLUG-PC “Server Stecker” [deviceIp=“192.168.63.151”]
And the item
Switch Shelly_Out “Server Outlet”{channel=“shelly:shellyplugs:SPLUG-PC:relay#output”}
Number Shelly_Power "Server Power " {channel=“shelly:shellyplugs:SPLUG-PC:meter#currentWatts”}
Number Shelly_Usage “Server total” {channel=“shelly:shellyplugs:SPLUG-PC:meter#totalKWH”}
So where im wrong ?
Ciao Gerd
Try to add the using the UI first, then compare JSONDB with your definition
I’m still struggling to get my Shelly button to work. I’m able to add the thing and link all items => items are populated with data.
But when I press the button, nothing happens, no logs, nothing. Enable CoIoT Events is enabled in OH & in Shelly GUI (Enable CoIoT).
When I toggle the Enable CoIoT Events option, I see changes in the Event, LastHeartbeat… channels, but not when I press the button. I actually only need the trigger channel to be triggered, but never saw this happening.
Running OH 3.2
Please enable TRACE logging. Is OH on the same sub net as the button? is there some kind of firewall in between. The WiFi access point nerds to be in bridge mode or support IP Multicast routing.
Is there someone who wants to support Plus/Pro testing (it’s in status experimental)?
2 Likes
Very timely. Just invested in a few Shellys. I have a Shelly Plus 1 Relay Switch. If you have the URL for a JAR, I would be happy to install and see what happens.
Thank you for your continued effort on this.
Hello, I have the same problem. I am configure a “thing event” on a shelly i3 button, but it will not working.
@markus7017
- TRACE logging enabled → no log
- OH is in the same subnet as shelly i3
- no Firewall
- WiFI access point support Multicast
Tcpdump is show me a udp packet when I push the button and in the debug log from openhab there is no entry.
Regards
Jürgen
18:15:07.014690 IP 10.1.2.42.5683 > 224.0.1.187.5683: UDP, length 166
0x0000: 4500 00c2 f767 0000 8011 54dd 0a01 022a E…g…T…*
0x0010: e000 01bb 1633 1633 00ae 0ad7 501e 5a9d …3.3…P.Z.
0x0020: b363 6974 0173 ed0b ec09 5348 4958 332d .cit.s…SHIX3-
0x0030: 3123 3938 4344 4143 3246 4342 3431 2332 1#98CDAC2FCB41#2
0x0040: d243 9600 824b 00ff 7b22 4722 3a5b 5b30 .C…K…{“G”:[[0
0x0050: 2c39 3130 332c 305d 2c5b 302c 3231 3031 ,9103,0],[0,2101
0x0060: 2c31 5d2c 5b30 2c32 3130 322c 2222 5d2c ,1],[0,2102,""],
0x0070: 5b30 2c32 3130 332c 3232 5d2c 5b30 2c32 [0,2103,22],[0,2
0x0080: 3230 312c 315d 2c5b 302c 3232 3032 2c22 201,1],[0,2202,"
0x0090: 225d 2c5b 302c 3232 3033 2c31 355d 2c5b “],[0,2203,15],[
0x00a0: 302c 3233 3031 2c30 5d2c 5b30 2c32 3330 0,2301,0],[0,230
0x00b0: 322c 2222 5d2c 5b30 2c32 3330 332c 305d 2,”"],[0,2303,0]
0x00c0: 5d7d