EspMilightHub new binding for milight limitlessLED and easybulb

matt1 · December 24, 2020, 3:02am

It is not a bridge config as the bridge is now handled by mqtt binding and not this one, all configs are done per child thing. I will make another build when I have time that makes this the default for your globes. Busy few days coming up no time.

I suspect you have not ticked all the needing boxes in the setup of the hub which is why the bulbMode is not changing state.

rastus_rob · December 24, 2020, 3:08am

Just quick question, how do I add ‘powerFailsToMinimum=false’ to each child thing, tried a few things, I failed LOL.

EDIT: nevermind, just add in square brackets at end of Thing definition (incase anyone was wondering).

Thing mqtt:rgbw:0x123A1 "Milight Bedroom Lamp" (mqtt:broker:0x123A) @ "Bedroom" [powerFailsToMinimum=false]

rastus_rob · January 6, 2021, 12:43pm

@matt1

I went to the github repository at “GitHub - Skinah/EspMilightHub: openHAB Binding for the esp8266milighthub” and it was marked " This repository has been archived by the owner. It is now read-only. ".

Where is the currently active github repo, and where do I raise issues ?

matt1 · January 7, 2021, 2:11am

The binding is almost merged so a milestone release will soon have the binding built into openHAB 3.x

GitHub is only for confirmed and narrowed down issues. Use the forum if not narrowed down to a bug as it could be user error.

Openhab has its own GitHub for merged addons.

rastus_rob · January 7, 2021, 8:02am

I already mentioned them here recently but they weren’t replied to. All these worked in OH2, since OH3 they no longer work.

1/ the binding isn’t listening or acting on MQTT messages, like when I turn on a light from the Remote or change the Brighness or Mode it always reflected this in the UI, doesn’t now. [High Priority]
Have double checked this with ‘mosquitto_sub’, the messages are going through from the UI and/or Remote, just binding isn’t responding.

2/ chosing a Disco Mode no longer sets that mode at all, used to. [High Priority]

3/ the Current Bulb Mode is no longer displayed, again, used to. [Medium Priority]

Matt, also, do you have a link to the new GitHub repo?

matt1 · January 8, 2021, 1:01am

You did get replies, see above. You really should not take over a large thread, but open a new one as is the norm for this forum. This way all the relevant info is far easier to find.

What does the TRACE level logs show, does the binding in trace level show it receives the mqtt message and what does it contain? Without exact info I can not comment. This is why it needs to be in its own thread.
What happens when you send the MQTT message manually? what does the binding send and does it send the wrong thing?
See above two replies, they apply the same to this.

Make sure you are using the latest build which I made changes in it for you last week. These went into the merged binding.

Before posting on GITHUB it is expected that you raise things on the forum here first and that you narrow it down. Github is not for tech support or asking questions.

rastus_rob · January 8, 2021, 1:14am

@matt1 I asked about using GitHub because different developers have different ways to deal with things.

I’ll setup trace level logs and start a new thread.

Rumfy · January 18, 2021, 7:45am

Hi Mordor, I have the same issue, I can’t see the extension for MQTT when adding it from my inbox in OpenHab 3. I did change the samba.cfg as well as you mentioned here. But I am still unable to get this mqtt extension for my milights after upgrading to OH3. Any idea on what I’ve missed here?

matt1 · January 18, 2021, 11:12pm

When was your jar file compiled? Did you unzip the jar and place it unzipped into the addons folder? What path is the addons folder?

Rumfy · January 19, 2021, 6:39am

Hi Matt1 I unzipped it and put the file “org.openhab.binding.mqtt.espmilighthub-3.1.0-SNAPSHOT.jar” in my addons folder: \openhabian\openHAB-share\openhab2-addons
I did this last sunday (2 days ago).

And as an addition to this, I also had to edit the frontail log service via SSH because it was still pointing to the old openhab2 directory after upgrading to OH3. Maybe I need to change a config file somewhere to point to the right addons folder for OH3?

The lights are my biggest concern because I use it a lot.

Mordor · January 20, 2021, 8:07am

Did you do an Chmod ?

For me its not under mqtt.

Rumfy · January 20, 2021, 8:14am

I did for the addons folder, this is what see:

Could it be that the openhab2-addons folder is the old OH2.5 folder and thus not being activated? Is the location for OH3 in another location?

The OH3 location documentation states that > /opt/openhab/addons should be the location for manual addon installation, but I can’t see it through ssh on my openhabian raspberry pi:

matt1 · January 20, 2021, 11:57am

your in /opt/openhabian/ which is NOT the same as /opt/openhab/

Then you are not using the latest V3 version of the binding.

When you click on the MQTT binding you should see these to add manually if the JAR is getting seen…

Rumfy · January 20, 2021, 12:08pm

Correct but I did that just to check what was underneath. If you see the same screenshot 1 command earlier you can see me put out a “ls” command which only shows an openhabian map.
But thanks for pointing this out to me. I’m almost certain that it is an issue with setting the right addons folder under permissions after the upgrade to OH3.

UPDATE > FIXED IT: I managed to fix it with sftp. I saw in the user share that there are 2 folders for addons:

I moved the jar file from openhab2\addons to openhab\addons, rebooted and voila. I am now able to add milights.

Thanks all!!

Hyperdomi · January 23, 2021, 9:14pm

Hi guys,
do I need MQTT to get this binding working or can I use it like all “normal” bindings?

Thanks

matt1 · January 24, 2021, 12:10am

This binding needs a mqtt broker setup. However openHAB does have a different milight binding that does not need mqtt, but see the very first post in this thread as to why people use the mqtt version.

matt1 · February 1, 2021, 7:09am

Binding is now built into openHAB v3.1 Milestone 1 and newer that was released today.

Readme is now found on the website with all the other documentation here:
EspMilightHub - Bindings | openHAB

Thanks to all those that helped test before it was merged to get things fixed and the people who reviewed the code to get it merged.

DrRSatzteil · March 22, 2021, 7:39pm

Just stopping by to say thank you for this wonderful binding. It works very well for me and was easy to setup for the most part.

I’ve got one suggestion for the documentation though since I had to figure that out for myself: it should be mentioned that, if you want to control your devices with group ALL in addition to the specific bulb group you need to add a separate thing (as it was not autodiscovered at least for me) for the group and connect it to the same items.

Edit: This brings up another question: I now have both things (the one for my led stripe on group 1 and group 0/ALL) linked to my items. So when I switch the light ON or OFF the command will be sent to all the brightness channel of both things. This is ok for me since I do not use the other groups right now but if I did I would always switch all devices on or off even if this wasn’t my intention. It’s there a simple way to tell OH that it should only send commands to one of the linked channels or do I need separate items for the group and use rules to propagate a group change only unidirectional to the single devices?

matt1 · March 22, 2021, 11:13pm

Good point, can you add it to the docs after your second issue is resolved? There would be two different approaches to adding a ‘group’ control.

Using openHABs built in group feature that allows any number of lights to be grouped as often you have lights with 5 globes in them and the milight group 0 can only do 4. This is how I run mine.
Use the remotes group 0 ability which will always change all the 4 lights. Yes you need to manually add them.

Think of it as modelling only light globes instead of modelling the controls in openHAB based off the remote control buttons. Two different ways.

Sorry I completely do not understand what your issue is, nor what the question is. Can you reword it and then read it again considering how another person may not understand?

DrRSatzteil · March 23, 2021, 6:40am

Yes I can suggest a documentation change for the group handling. I solved it like you described in 2. but due to my second issue I may change this to your approach 1.

No worries if you did not understand what I meant with the additional question, let me try to explain differently:

Right now I have two things, one for group 1 and one for group 0 (ALL). For simplicity however I just linked the brightness and color temperature channels of both things to the same item as you can see in the attached screenshot Screenshot_2021-03-23-07-33-23-247_org.openhab.habdroid|230x500

This works fine as long as you only use one group in addition to the ALL group but will cause a change of both groups whenever you send a command to the item: if you change the brightness item for group 1 OH would send this command to the group 0 and group 1 things. By changing the group 0 it would also change e.g. group 2 item if it was setup the same way (linked to groups 2 and 0 things). I hope this makes it a bit clearer.