I’ll come up with the beta1 this week. @igi, @MHerbst and I spend more time on testing so could got RGBW2, Bulb and Sense fully working and testing.
To your question: Yes and no. I still want to optimize the channel/thing updates by checking the current status and post only changes. This is build in, but we were missing some initial updates so it’s disabled at the moment. This will be done after releasing feature 1. I just want to make it stable before starting to change - there is always a chance to fail
I already put in some notes in the README on new/updated features. Please let me know If you are missing a feature, a setting or a channel.
fyi: For now I’m back on the master branch. Once beta1 is done I create this branch and will then continue in a snapshot branch.
Hi, beta1 is done. Last addition was support for http basic auth so you could set a user/password. Could someone verify that (master branch) so I could close the release?
I’ve just tried with a plug-s.
The autodiscover (obviously!?) does not work with restrict login :
Device discovery failed for device shellyplug-s-7af169, IP 192.168.10.33, service=shellyplug-s-7AF169: Shelly API call failed on url=http://192.168.10.33/settings, response=401 Unauthorized: ERROR from : Unexpected http resonse: 401 Unauthorized, url=http://192.168.10.33/settings - class java.io.IOException (class java.io.IOException)
Does it make sense to move login settings in the binding settings? Or it’s better to keep it to thing level?
Maybe have both and using the binding login settings as a fallback?
Anyway adding the thing manually it stays in INITIALIZING and never comes online, it’s like the basic auth is not used:
==> /var/log/openhab2/openhab.log <==
2019-08-16 21:16:47.742 [INFO ] [helly.internal.handler.ShellyHandler] - Start initializing thing Shelly Plug-S (SHPLG-S), ip address 192.168.10.33
2019-08-16 21:16:47.744 [TRACE] [helly.internal.handler.ShellyHandler] - HTTP GET for : http://192.168.10.33/settings
2019-08-16 21:16:47.764 [INFO ] [helly.internal.handler.ShellyHandler] - Unable to initialize thing Shelly Plug-S (SHPLG-S): Shelly API call failed on url=http://192.168.10.33/settings, response=401 Unauthorized: ERROR from : Unexpected http resonse: 401 Unauthorized, url=http://192.168.10.33/settings - class java.io.IOException, retrying later
2019-08-16 21:16:47.766 [DEBUG] [helly.internal.handler.ShellyHandler] - Update status job started, interval=20*3=60sec.
I’ve been testing my RGBW2’s and I notice that on very rare occasions they flicker once and then continue to operate normally. Has anyone else come across this? I’m not sure if it’s because of openhab, the binding, the shelly itself or some other reason.
that’s correct, there is no way to get around that
Please check out the current build. I replaced encoding the auth data in the url by using the http header for basic auth. Make sure to use the build in the master branch.
I’ll implement binding settings as defaults. Using the header attributes it’s transparent even one of several things doesn’t uses basic auth, but the data is set in the binding config. In this case the auth data is send, but not processed by the device.
Could you please try the last build and provide feedback.
please provide a TRACE log then we could verify if the binding is causing this effect. Please provide a step-by-step description of the flow so we understand when this happens
Roller: Shutter control channel is now “control”, channel “turn” are removed (use control instead) as well as and “calibration”
Roller new channel “rollerpos” has the position based on 100=open, 0=closed (vs. “control” with 0=open and 100=closed, e.g. for a vertical slider in HABpanel)
new thing config options to enable/disable setting of relay event urls
output binding version and build timestamp into the logfile
support for basic auth added (handled userid/password protected device)
config options on the binding and the thing level for basic http auth
ignore UP/DOWN command while roller is moving
fix: process roller command STOP again
fix: don’t turn light back on after set color with OnOffType.OFF
fix: recover HT when not available on initial thing initialization
fix: various problems in the xml definition fixed (duplicate entries)
No, it’s not - Is that the only device?
Usually this is the result when a device type is not defined in the xml, but shelly25 is in there
Do you see a message in the log?
There was one change when using FullColor in combination with Brightness=0, but I’m not sure if this could be caused by the binding. Be happy: Usually people complain about features broken by an update
Do you see any performance issues due to the fact that you have 13 Shellys? I won’t expect so if you have moderate polling (15 or 60 or > 60sec), just for interest.
I just started again working on Coap and facing the same problem: Receiving nothing, but seeing “unsupported Options” in the log. I couldn’t find any sample using custom coap options. Maybe I need to debug the Californium code. The Shelly guys couldn’t help just provided a Node JS example, which implements the nessesary part of the Coap protocol itself. My feeling is also that Californium is over-driven for the functions we need. Anybody welcome who wants to support here.
Does anyone already got a Shelly 1 EM or a Shelly flood. Happy to work on integrating them.
Do you see any performance issues due to the fact that you have 13 Shellys? I won’t expect so if you have moderate polling (15 or 60 or > 60sec), just for interest.
I’m running an Ubuntu server VM on a Ryzen 7 1700 and a Unify setup. So plenty of juice here. So far I’m extremely happy with the binding even though there still might be a few bugs that need fixing. It made me buy additional Shelly’s.
One thing that could be a different project is a dedicated widget for the RGBW2. The current widgets don’t give the proper control. I’ve been playing around with it myself but I’m a total noob at html css json etc. so the learning curve is quite steep.
me too
could anyone support here? I’m very interested in a HABpanel widget (or multiple) to support the various devices and features as nice compact widget
)
The Shelly guys couldn’t help just provided a Node JS example, which implements the nessesary part of the Coap protocol itself. My feeling is also that Californium is over-driven for the functions we need. Anybody welcome who wants to support here.