Thanks for reporting, I have looked into this and the hub only uses uppercase so we also need to ensure uppercase is used. From the next build the binding will put an ERROR in your logs if it detects you are using lowercase in your UID for your things.
Yes that will happen but it should not cause issues at least in the way I use my system I see it as a feature as I always want colours to be full brightness as they are duller than white which I may prefer to be dimmed down. Does this cause an issue in your use case? If you can describe how it causes an issue, then I can work out what will work for both use cases.
@furax54
EDIT:
I could propse adding a new option called “link white and colour controls” with the ability to turn this on or off.
OFF: (This is how it works currently)
The Slider for colour does not follow the level slider when globe is in ‘white mode’.
When in ‘colour mode’, both sliders move each other.
When in ‘white mode’ the colour on the selector wheel stays on the last used colour.
When you are in white mode and select a new colour the level slider will jump to your last used brightness for colours.
When you select white mode from colour mode the level slider jumps back to the last used white brightness.
ON:
When in both ‘colour’ and ‘white’ modes, both sliders move each other at all times.
When in ‘white mode’ the colour on the selector wheel moves to “0,0,level” which shows as white on Openhabs controls.
I can see that some users may only implement a colour channel for RGBW globes in habpanel to save space and this feature may be useful? Any ideas on how it should work? Does that cause issues for anyone?
Actually, I think the current implementation fit to my needs. And if I want, I will add a rules for a different behavior becasue the option you propose have a global scope.
It is not global as it is the options for what is called an Openhab BRIDGE. The binding can have multiple bridges setup all going back to the same MQTT broker, and each one can have its own settings different to the others. This allows groups of globes to have x settings and others to have different ones. Of course I have never tested this for bugs but it should work.
I - finally - succeeded in running my RGBW LED controller FUT027 with the RGB protocol. The RGB (without W) is needed, because with that controller white light is handled as a mode which needs to be selected.
However, upon every colour selection the intensity goes back to 255. MQTT sniffer tells me: {"state":"ON","brightness":255,"bulb_mode":"color","color":{"r":255,"g":0,"b":114}}
and 10 times {“command”:“brightness_up”}.
(If I were a device I would even glow at 200% after such motivation )
Is there any way to get around this behaviour? I would like to change the colour and brightness separately.
You need to follow the setup instructions more carefully. Brightness should not show up in the mqtt messages it should be changed to level so please read the readme and first posts of this thread.
Thanks for your comment! I did now change the setting in mqtt Group state fields, but I still receive the cascade of “brightness_up” after the color change which leaves me with high intensity after each color change.
But I found at least part of the origin.
The L-Value of the colorpicker in the HABPanel as well as the brightness slider can only change the value of the brightness to higher values. Lowering the slider still increases the brightness.
Commands as {"state":"ON","level":27,"hue":210,"saturation":100} which are detected by the mqtt sniffer work correctly. However, I see more packets, e.g.
{"state":"ON","level":27} #this command alone would be correct!
{"state":"ON"}
{"command":"brightness_up"}
{"command":"brightness_up"}
{"state":"ON","level":80,"hue":121,"bulb_mode":"color"}
Strangely, sending {"command":"brightness_up"} via mqtt does not produce any reaction.
So I am a bit lost.
I suspect these are still from not following the setup instructions, in particular …
mqtt_update_topic_pattern
leave this empty
Either that or maybe a bug in the firmware. You need to test using manual sending of MQTT messages and then if it is a bug post in the github project for the hubs firmware with clear instructions on how to reproduce. For example I have no idea which bulbs you have nor what the MQTT topics the messages are coming from.
thank you for your continous help. update was indeed not empty.
Still the problem is continuing. It seems to be part of openhab’s control.
repeated clicking on the dimmer gives me 1st a correct mqtt response like {"state":"ON","level":14} but it is followed by another response which changes every time I repress the slider at the same level.
{“state”:“ON”,“level”:14}
{“status”:“ON”,“level”:70,“hue”:227,“bulb_mode”:“color”}
{“state”:“ON”,“level”:14}
{“status”:“ON”,“level”:80,“hue”:227,“bulb_mode”:“color”}
{“state”:“ON”,“level”:14}
{“status”:“ON”,“level”:90,“hue”:227,“bulb_mode”:“color”}
{“state”:“ON”,“level”:14}
{“status”:“ON”,“level”:100,“hue”:227,“bulb_mode”:“color”}
If I send the command `{"state":"ON","level":14}` manually, everything is fine :frowning:
I am still running OH 2.4 on a synology NAS (the synology packet of OH 2.5 is not yet ready...)
Anyhow, I will probably make a break and recheck, once the new synology package is available.
Hi, I followed the whole tutorial, but somehow it does not work, also I am not an expert in those things.
First of all, I found it confusing that mosquitto is not written as prerequisite to make it work. Before I installed it, OpenHAB found my HUB, but it was all the time offline. Just after installation it is online, but somehow it does not communicate with HUB. My mosquitto instance is on the same IP as OpenHAB, so in the config I have left “tcp://localhost:1883”, while in HUB I have put “tcp://openhab_ip:1883”, put all the strings for configuration as in this tutorial, and still mosquitto_sub does not show anything. What might be wrong?
Thanks for the feedback, I’ll need to update the readme shortly with the changes in this reply…
The readme does state this currently…
You do not need to have any mqtt bindings installed as this binding is fully standalone and uses the java Paho library. This does not mean you do not need a MQTT broker somewhere reachable on your network.
I’ll make it clearer when I rewrite it with the below info…
In the last 1-2 months a new MQTT version 2 binding has been released which when installed will create an installation of mosquitto for you with a single mouse click. I have not done it yet so this is what I understand happens. I just went to the documentation and it appears to have nothing on this new V2 binding, it is probably a post in the forum somewhere?
I would recommend you uninstall any extra copies of mosquitto and to only use the one inside the new binding because it gives you the ability to auto detect and setup certain devices. I say uninstall the other mosquittos because they may cause issues with the V2 mqtt bindings version if they both try to use the same port and perhaps that is the issue you have?
Mosquitto creates a log file, so be sure to find and open the log file as it will contain clues as to what is going on. You will need to use google/this forum to find out where this log file is located for the new binding…
Yes this is confusing and needs fixing as the readme states it does not need any additional bindings, but hopefully the above has cleared it up? If you can not connect to the broker/mosquitto using the sub command then that issue will need to be fixed first. Hopefully it is from multiple mosquittos installed on the same system conflicting.
Mosquitto is an MQTT broker. But it is not the one that is used by openHAB. We have an embedded MQTT broker that is NOT started by default, it is not even installed by default. (It’s name is Moquette btw.) But you can install it via Paper UI, in contrast to Mosquitto, which you need to install to your operating system via other means.
You must in both cases add an MQTT Broker Thing (that basically connects to the MQTT broker, no matter if it is Moquette or Mosquitto). The difference is, that we can do an autodiscovery for the embedded MQTT broker, so it will appear in the Inbox, while a MQTT Broker Thing for Mosquitto would need to be added manually.
@copytco Readme has been updated to hopefully make it clearer and download link removed so people have to enter the readme to find the link to download the binding from now on. All info is now in the same place, that is the readme.
Not sure if I am having a problem with the MQTT Embedded Broker or the ESPMilight Binding and Lower case device id. Please help me learn how to figure this our or if you have solved it. I would be very greatful. I have learned some things about MQTT as I’ve struggled but now have been stuck for several days. I had the EspMilightHub working on OH w/Mosquitto but want to make use of the embedded MQTT.
Everything seems to install OK in the PaperUI except the discovery for the Globe does not work. I can add it manually and it shows online but doesn’t respond.
Ive tried many combinations thank to Checkpoints. I have gotten the closest by using a clean install of OH and only adding the Embedded Broker and ESPMilight Hub binding. I’ve checked that the config of the Milighthub matches the readme and the user/password, address:port, match between the ESPMilightHub & Embedded Broker Service and the ESPMilightHUB Thing. I have installed Google Lens and watched MQTT but the only messages I seem to find “milight/commands/#” messages when using the remote or the EspMilight Hub control panel. The log messages for the request from OH look like the ones I recall when using Mosquitto such as “;Item ‘RGBCWWWGlobeControlledViaFUT089RemoteFut089_Level’ received command ON”; or “RGBCWWWGlobeControlledViaFUT089RemoteFut089_Level predicted to become 100”; but no effect on the bulb and no evidence in Lens/MQTT. If there is something I should subscribe to besides the config in the Hub please advise.
On startup, the log shows that the EspMilightBridgeHandler could not connect to MQTT Broker and there is a [ERRROR] “The Milight GLobe 2f027bfa is using lower case for the remote code when the hub uses only UPPERCASE”. When I look in the EspMilight Hub config the device Id 0x89C1. This message is followed by repeats of [ub.handler.EspMilightHubBridgeHandler] - Error: Could not connect to MQTT broker. I also notice that when the Hub is in dioscovery that PAHO message comes up, [nternal.EspMilightHubDiscoveryService] - EspMilightHubDiscoveryService is now looking for new things
[.moquette.spi.impl.SessionsRepository] - Session does not exist. CId=paho10618602363402
The binding can not connect to broker ! Of course the binding will not work and no messages will be seen in the broker if it can not connect. This MUST be fixed first. Check user and passwords are correct and if they use non standard English characters try changing to see if it is a clash of characters.
The readme has a section titled something like 'IMPORTANT FOR YOU TO SUCCEED" please read it at least 3 times and tell me if it does not make sense. I will happily re-word it if you find it confusing and explain why… The globe with unique ID “2f027bfa” will not work and that section explains why. Once you fix point 1 you will be able to use autodiscovery and this wont be an issue.
EDIT:
This may be an issue as MQTT has what is called persistant sessions and the binding uses this feature. If you get a drop out in your connection only new/missed MQTT messages get sent between the broker and the binding and not the entire list of globes and states. Possibly this feature in moquette is not enabled or has an issue? See Davids post above, you can use Mosquitto from what I understand to do autodiscovery if that is the reason why you wanted to change, you just need to add a MQTT Broker Thing manually. I would prefer to use Mosquitto purely for the reason that if you google an issue 99% of the help will be about Mosquitto. I also saw that a number of bugs were fixed for the embeeded MQTT broker in the 2.5 Milestone over the 2.4 stable build.
My interest in Moquette was that initially it seemed that it made for a simpler architecture. Since that point has seemingly passed I suppose I am only just obsessed with making it work. Maybe Moquitto is the way to go. As you said and as I’ve seen the autodiscovery works that way.
I have amended the embedded broker readme to explain a bit more about mqtt concepts, renamed the embedded broker to “Mqtt broker Moquette” and also name mosquito as alternative.
The readme for this binding is at the below link. I have had a user post that they have it working with the embedded broker, not sure if they are using the latest build.
yes, but the location will change this weekend, when the bundle has been migrated to the new build-system. At that point my readme changes will be in as well.
matt1:
Reread as suggested. Also considering the report it was working in another instance I tried a clean install of OpenHab 2.5.01 today and was stopped again at discovery for the globe. After looking at the log I have a question if the hub binding is really online despite the green light.
Steps taken:
I cofigured the broker service with a new user / pswd and then changed the ESPMilightHub to point to the new IP with the new user and password. The HUB was reported identified and installed but the in the subsequent try bulb is not found. I also did not see the screen asking what sort of buld to look for. I tried the “trace” logging but didn’t see any change. I installed Maven in an attempt to get Moquette to tell me more but no joy for me there.
Below are HiLights:wink: from the log and an attached document with screen shots of config and the log file.
Summary:
The HUB was not initially able to contact the broker (Check password)
Then the embedded broker was reported offline and then subsequently that it was starting
The PaperUI was then started
EspMilightHubBridgeHandler] - Sucessfully connected to the MQTT broker.
Then EspMilightHubBridgeHandler says "espmilighthub:esp8266Bridge:Auto001’ changed from OFFLINE (COMMUNICATION_ERROR): Could not connect to the MQTT broker, check the address, user and pasword are correct and the broker is online. to ONLINE
)