Hi matt1.
Openhab is 3.2, binding version is .wled-3.3.0-SNAPSHOT and Wled version is the latest.
Im sending onoff command with a switch on channel Master controls.
If you have done an upgrade, try deleting and re-adding the thing. When new channels are added it can be necessary to do that in openhab. Based in and off commands are well tested so I suspect it will be the need to delete and re add causing it.
I did that with wled-3.2.0-SNAPSHOT and also with wled-3.3.0-SNAPSHOT. I deleted items and things.
There is no difference in behavior.
If wled device is turned OFF in webui and you turn it ON from openhab, you can see that power button changes from off to on.
If wled device is turned ON in webui and you turn it OFF from openhab, you can see that power button stays ON.
Please read the above multiple posts about the binding not controlling the GLOBAL on/ off. There is a picture that explains the segment master VS global that should make it clearer.
I also have the same behavior(
My setup:
OH 3.3.0 Build #2721
WLED Binding 3.3.0.SNAPSHOT
Wled ESP8266 v0.13.0-b6 with 11 Segments
I can control only ONE segment with a switch on channel Master controls, the same with brightnes. And sometimes ESP8266 reboots after command from OH.
This would be cool. When is it planned to be implemented?
Ok. I tried also with segment brightness and I am getting the same behavior as with master controls.
Next preset powers on lights.
Any other suggestion, that i could try?
There was one bug in the 3.2 stable binding which broke the on/off status and matches the issue you describe in your very last post. This is fixed in a jar you can download that is mentioned in the above posts, or the next milestone (due out any day now) will also be fixed as the changes were already merged. If your not using the fixed jar then that should be done as a first step.
@marsic
Its probably 10 hours work that I have not started yet. Just need to wait for some spare time on a rainy day. I may split it into two chunks, 1. add bridge and thing design with the global channels. 2. Add the improved discovery. The idea would be to try and get the first lot changed so it can be tested in the milestones before 3.3 Stable.
with which channel i can just power off the LEDs and on ?
Fully covered in the docs.
I have created a switch on channel mastercontrols like:
Switch WZWLEDAmbilight āon/offā {channel=āwled:wled:40f52XXXX310c8:masterControlsā}
But it wont work. (wled binding 3.2.0) if its off I can turn it on but not vice versa
That is the bug, read above.
New build created for anyone that wants to test:
- Bridge/thing structure now used
- Global channels added
- Lower system load as the bridge parses the data once for all segments.
Index of /openhab/wled/ (pcmus.com)
You will need to delete all things and also clear your cache as this is not backwards compatible.
1 Like
Generally works well.
Just tested:
- Global thing works fine
- Segment thing has some issues, Effects not showing a list of all available, only number of current effect, the same with Palettes.
ā¦it would also be nice to have global settings for effects, palettes and colors
Effects and Palettes are now fixed in the JAR at the link in my last post, thanks for reporting.
colors should be easy, just create a group item and make all the masterControls a member of that group. openHAB will then send the same colour command to all members of the group. Iām not sure if the same thing will work for the effect and pallete channels.
How would you propose that would work?
Checked out your new JAR, now the list of effects and palettes displayed properly))
Groups in OpenHAB are certainly good, but for example, for 20 segments, you will have to create 20 things + global thing, and then for most settings, manually create group items. And it is just one Cristmas tree with lights.
Itās not a problem for me, but for beginners it looks not quite easy))
It would be much better to have all the settings for both the global things and the segment things. And then each person will be able to decide what they need. Separately manage segments ā use segment things + global things. Need to manage the entire led strip, even if it is divided into segments, then use only the global thing. There are many user cases where you need to divide the LED strip into segments, but use the same settings for all segments.
But thatās just my opinion)))
However, even in the current implementation, everything is pretty cool)) Thanks for the great binding))
Can you explain why you have 20 segments on a single Christmas tree? Is this a mega tree made up of 20 strings going from 20 points around the bottom, routed straight up and all joining at the top? Understanding the use case helps as I just use a single segment on the tree. Why split it up into 20 and then want to control them all at the same time as a single light?
There has to be a balance between being flexible to do everything you want and also being simple enough that having 100+ channels that are easy for a new user to understand. For example, with 20 segments a new user may see 80 different color channels (masterControls,primary,sec,ā¦) plus a global set of controls and totally not know where to start. This can be solved to some degree by marked them as advanced channels that are hidden by default.
- Stay consistent with how other lighting bindings work.
- Stay consistent with how other bindings group lights.
- Teach the use of groups that can be used in all bindings and situations.
Playing last night with the GUI of the WLED firmware, it really can do some things which are difficult to reproduce in a consistent way and Semantic model form that openHABās direction is headed in. Being able to select any 4 out of 20 segments and change the fx on just them is an example of this. Single segment yes can be done, all segments yes can be done, but being able to pick and choose any combination it becomes difficult. At some point we have to stop the complexity and try to promote consistency. As you wrote, this is just one persons opinion and interested in hearing yours as to where it stops.
A global colour, fx and pallete channels I am not against as they do make sense. Consider what happens if they did exist, you send a command and the lights all change to what you want, but the controls in openhab for all the segments dont update until the next poll time arrives. This may not happen as the API allows a response to be sent to provide an instant update which the binding already does this when possible. If you use a group item, this solves the problem and the controls will all be at the correct state at the expense that multiple packets are sent instead of a single request to the WLED device. With groups it may be possible to crash (or the esp may ignore some commands) the esp device with a flood of commands spaced too closely together, would be interesting to do the test to see what happens if groups are used with a large number of segments.
Thanks, if you notice anything that needs to be changed please let me know. I need to do the documentation changes and look at the auto discovery changes mentioned and then it can be submitted for getting merged. Still tons of work to be done, but in the meantime it can be used and feedback gained as the actual functionality should be close if not already done.
EDIT:
@marsic
Doing some testing last night I noticed that you can create segments that overlap. What is wrong with creating an extra segment in the firmwares GUI that is the whole string, then you can use that āsegment thingā to control the whole lot? Does this work for you?
New version of the binding can be found in the marketplace and now has discovery of all segments and will auto name them with what is saved in the firmware. Updated docs are also linked in this post.
Because with segmentation, the effects look completely different
You almost guessed it))) I just arranged the garland vertically, and divided it into segments:
If I use one overlapping segment, then the effect will still go from the beginning of this segment to its end, but I need the effect to start at the bottom of the Christmas tree and go up to the top, for example rising up circle.
FX Intensity and Speed, as well as Primary, Secondary and Tertiary Color are also make some sense)))
good option if possible
In the WLED GUI, I can choose which segments to manage globally by simply checking the boxes
Is it possible to do something similar for a global thing??
For example, some field in the settings of a thing where you will need to specify the numbers of segments that you want to manage globally?
I donāt know as the API documentation is not clear if this is possible and gives no examples. There is the ability to giveeach segment a selected switch, but how to send a API command to only the selected ones is not given.
It is possible your the first to ask to do it. Check on the discord for wled for an example json and if anyone does it.
But I still feel that we need to ask the question if we should do this and increase the complexity. Another way to do this is to use a WebView to display the wled UI directly. Then you have all features.