I’m very new to OpenHAB2 (Thus posting in the Beginners Topic), however, I cannot find a solution to either of my two issues in the forum.
I have a working setup with OpenHAB2 beta4 and mosquitto that is controlling a LED setup using ESPeasy dimming lights (via power MOSFETs) using PWM on the ESP8266 (sitting on pin 14). When sending commands using the command line e.g., :
mosquitto_pub -t /ESP8266/PWM/14 -m "999"
then this works flawlessly. The PWM commands to the ESP8266 are between 0 and 999 with the 999 is full effect and 0 is off. When adding this to OpenHAB2, I first created a .item with the following command
This is basically working, but I have two issues. The first is how to change the OpenHAB commands from being in the scale from 0-99 (i.e., percent values) to 0-999. Right now I thus can only change the dimming from 0 to 10% through the OpenHAB interface.
My second issue is that the stability of this control is right now very bad. While I can control the ESP8266 perfectly from the “mosquitto_pub”, the control from the OpenHAB dimmer is very infrequent. It works 2-3 times and then it just stops. Then maybe 10 seconds later it is working again. Using the “mosquitto_sub” command to monitor the relevant topic on the same server, I can see that OpenHAB is just not sending any commands via MQTT. As soon as it does that, then the LED responds. Therefore I suspect that the issue is within OpenHAB and not in MQTT or the ESP8266.
I also have two separate setups with ESP8266 devices and they share the same issue.
All tips are highly appreciated, as I said, I’m very new to OpenHAB.
In answer to your first question, you need to use a SetPoint, not a Slider. Slider apparently only supports 0-100.
Alternatively you can create a rule to interpolate these 100 steps (i.e. one step from the slider sends 9 steps to the device).
In answer to your second, that is indeed odd behavior. There has been some forum traffic recently that the Slider widget on the UIs is broken. This may be related to that. Can you confirm in OH’s logs (you may need to create a rule to trigger on this Item’s updates) whether the delay/lack of message is caused by openHAB not receiving the command from the UI or it gets the command and just sits on it, or generates an error?
Thank you for the quick and helpful reply. I have started to test your first solution and wil in parallel work on assessing the logs to provide you with more information on the second. The “Setpoint” alternative is indeed interesting. Unfortunately, I found this to have the exact same limitation. As long as I set the the “maxValue” below or equal to 100 it works as expected. If I set the maxValue to “110” for example it still only allows me to set it up to “100”. Am I configuring this the wrong way?
As another piece of information, a step decrease to “1” does not help. It is still stuck at 100 as a maximum. If I the “maxValue” to “90” then that becomes the max, to it is reading the parameter.
Short update.
What Rich suggested is indeed a solution is indeed a solution. What I missed before posting my previous post is that also the “Dimmer” function in the Sitemap file is limited to 100. When changing this to “Number” ot works as expected. It is a little slow to make large changes though so in the future I may try to make a rule so that I can use the Slider function instead, but at least for now this is a working solution.
Unfortunately, however, the intermittent function of the UI still remains when using the “Setpoint” function (i.e., that only some of the values are posted to MQTT). I will have to spend some time with the logs and will post back.
As a second update, I thought that I could share how I solved the scaling issue with a rule instead of the Setpoint approach. The “Rule” approach enables the use of a “Slider” in the sitemap but generating a MQTT published value between 0 and 1000.
I’m sure the code can be cleaner and better explained, but here is how I did it.
In the .sitemap file:
Slider item=LEDLIGHT_IN
in the .rules file:
rule "LEDLIGHT_IN"
when
Item LEDLIGHT_IN received command
then
var Number outNum = LEDLIGHT_IN.state as DecimalType
sendCommand(LEDLIGHT_OUT, outNum*10);
end
Then in the .items file:
Number LEDLIGHT_IN
Number LEDLIGHT_OUT {mqtt=">[localbroker:/ESP8266/PWM/14:command:*:default]"}
One thing I struggled with was how to avoid having the “LEDLIGHT_IN” item cluttering the .items file, as this has no function. However, if I take it away, everything stops working. If anyone has an idea, please let me know. Also, if there are cleaner/better ways to write the rule, please inform me, but at least this works.
Continuing on the stability issue I’m, still struggling with this. In the same .sitemap file, I have multiple sliders controlling both Z-wave devices and 433MHz (Tellstick) devices, and all of them work perfectly. It is only when the item has to send MQTT publish commands where I have issues. Tips on how to solve this would be highly appreciated!
A final post on this topic on the issue of the stability. However, I would appreciate if someone could spot which of the two things that solved it, for future reference.
The first thing I did was to re-install the bindings after clearing the cache using the following terminal command (Warning! you have to re-install all bindings after this, but all settings remain)
sudo rm -rf /var/lib/openhab2/cache/*
The second step I did and maybe this is the more important change (?) was to install the “MQTT Persistence” Extension. This I managed to miss the first time. Could this explain the error I was seeing?
At least the combination of those two things have made it all work well! So I will mark this as solved.
The scale transform is perhaps poorly named. It lets you choose a single value to use when the item value is within a range (e.g 85 to 110 maps to Hot). It does not just multiply the value by a fixed amount.
However, that could be done using a JS transform. But that wouldn’t be a significant reduction of code.
I solved a similar issue (MQTT controlled volume of a speaker - range 0-30) using 2 Scale transformations (one for incoming state update (30->100) and one for outgoing (100->30).
It took quite some lines since there is no ability to use the formula. Perhaps as you mentioned JS transform would be a better choice, since there I could use a formula for calculating values.
Anyway it would be useful if Slider would have a setting for min/max/step as Setpoint does
