EspMilightHub new binding for milight limitlessLED and easybulb

[hafniumzinc (T)]

@rastus_rob

I made the changes you mentioned, no errors now, but none of the lights work any longer.

Not ideal! OK, well, the error isn’t really an error: just an INFO message. If everything worked even with this message then I’d just leave it as it was!

[rastus_rob (RaSTuS)]

@hafniumzinc

@rastus_rob

I made the changes you mentioned, no errors now, but none of the lights work any longer.

Not ideal! OK, well, the error isn’t really an error: just an INFO message. If everything worked even with this message then I’d just leave it as it was!

Yeah, it didn’t affect functionality, I was just giving feedback to Matt basically.

[matt1 (Skinah)]

@rastus_rob

I’ll try that, just going off the Readme, thanks.

Only you did not use the readme’s example, you modified it as there was no curly braces. If you have problems try using exactly the format provided and also do a reboot. I had all controls not work on me today until I rebooted possibly as I was playing around with wrong configs.

I’ll take a look at your feedback after some sleep, but I distantly remember that some remotes don’t support going directly to X disco mode and they only work by sending the command to go up and down modes. Could be wrong.

[rastus_rob (RaSTuS)]

Paragraph 1: I’ll try this.

Paragraph 2: This is exactly what’s happening, up/down works, x discoMode doesn’t, Here is a pic of my type of remotes:

EDIT: tried without curly braces and didn’t work initially, restarted OH and now works fine.

I do have a few quiestions though, when the lights are set on/off they start in a dimmed state before going fully on or off, used to just start/stop at the brightness set, no dimmed transition in between. Another thing, they used to reflect the state of whatever button I used on the Milight remote, now they don’t.

[matt1 (Skinah)]

@rastus_rob

when the lights are set on/off they start in a dimmed state before going fully on or off, used to just start/stop at the brightness set, no dimmed transition in between.

This is fixed by making powerFailsToMinimum=false
I have changed the binding to make this false by default for the older globes.

@rastus_rob

Another thing, they used to reflect the state of whatever button I used on the Milight remote, now they don’t.

That works here, are you using group 0 or a group 1-4 when this happens?

[rastus_rob (RaSTuS)]

@matt1

@rastus_rob

when the lights are set on/off they start in a dimmed state before going fully on or off, used to just start/stop at the brightness set, no dimmed transition in between.

This is fixed by making powerFailsToMinimum=false
I have changed the binding to make this false by default for the older globes.

@rastus_rob

Another thing, they used to reflect the state of whatever button I used on the Milight remote, now they don’t.

That works here, are you using group 0 or a group 1-4 when this happens?

I added ‘powerFailsToMinimum=false’ to the Bridge config, restarted OH3, but made no difference.

Bridge mqtt:broker:0x123A "Milight LEDs" [ host="192.168.0.xxx", port=1883, secure=false, username="", password="", qos=1, powerFailsToMinimum=false]

The ‘bulbMode’ is not working on all groups (0,1,2,3,4) in PaperUI, in OH3 interface it shows up as ‘NULL’.

[matt1 (Skinah)]

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 (RaSTuS)]

@matt1

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.

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 (RaSTuS)]

@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 (Skinah)]

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 (RaSTuS)]

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 (Skinah)]

@rastus_rob

I already mentioned them here recently but they weren’t replied to.

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.

1. 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.
2. What happens when you send the MQTT message manually? what does the binding send and does it send the wrong thing?
3. 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 (RaSTuS)]

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

M5paper interface panel

Thanks. I plan to include WifiManager for configuration of network and other settings. For the label / buttons configuration, I’m still looking for a clean way of doing. I’d like to avoid another configuration menu while still allowing customization. I’m considering to use a sitemap, but this still has to be tested. And, yes, for bugs I prefer github issues.

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

[Rumfy (Remon Lardenoije)]

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 (Skinah)]

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 (Remon Lardenoije)]

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]

Did you do an Chmod ?

For me its not under mqtt.

[Rumfy (Remon Lardenoije)]

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 (Skinah)]

@Rumfy

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

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

@Mordor

For me its not under mqtt.

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 (Remon Lardenoije)]

@matt1

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

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!!