Thanks. What you try to operate is a lighting controller. Channel 14a0bce4-00fa-bd24-ffff13887f83ecc5 accepts only numerical or UP/DOWN values that selects a mood. To mix moods you can send ON/OFF to an individual mood for example 14a0bce4-00fa-bd24-ffff13887f83ecc5-M1.
To control an output, for example ColorPickerV2, where you can send HSB values and ON/OFF commands, you need to send the commands to an output channel, for example 14a0bce4-00fa-bd24-ffff13887f83ecc5-AI1.
You can check out the documentation where are the details about what commands are accepted by which channel types: Loxone - Bindings | openHAB
For the other problem, could you also provide what exactly functional block do you operate (from LoxAPP3.json).
Sounds complicated. But thatâs the reason why I want to remove the loxone app and replace it with openhab.
With your direction, I noticed that I use the 'light controller modules" in loxone, and not the actual lights. When I visualise the actor in loxone, I can now see nicely the status in openHAB. Sadly I canât control it (yet)?
When I check the âlight controllerâ in the openHAB log, I see following in my logs when I switch the light in the Loxone app from OFF to ON, and from ON to OFF:
2021-03-03 14:38:21.773 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item âZD_H_Verlichting2â changed from ON to UNDEF
2021-03-03 14:40:29.782 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item âZD_H_Verlichting2â changed from UNDEF to ON
So this look like to be inverted?
Guess that I need to have a kind of virtual switch in Loxone for this?
ps Iâll focus myself just on a normal light (ON/OFF) before starting with the tree RGBW lights.
Lights connected to lighting controller as subcontrols (their channels end with -AIn)
Moods defined in lighting controller (their channels end with -Mn)
You can only send numbers to lighting controller, not ON nor OFF. The number selects a mood in the controller.
You can send ON/OFF to lights, when they are represented as switches in Loxone Config
You can send ON/OFF to moods to mix them in or out
When you turn the light on in Loxone app, you need to look at the state of lights, not the lighting controller. What you look at is likely lighting controller. It goes to UNDEF, because there is no mood that corresponds to the single individual light you turned on or off or OH does not know how to translate the number (mood) to switch value.
At first sight, the lights (actor ON/OFF) are working now, with the light controller + AIn.
Sadly, this is a remote site, so I canât test right now all functions. Just a view on a camera. So later on, Iâll test if all works as expected (in combination with hardware swichtes in the room and so).
I was trying to figure out the tree RGBW lights, but seems these arenât working the same way? These are known as SMA block after the AQn (see printscreen below). But I canât visualise these? That option isnât there.
Great, I am glad you got switches working.
SMA output is smart actuator. You can control is through the output of the lighting controller, but first we need to figure out what kind of an output this is. Please look at LoxAPP3.json and find the lighting controller part and post the part which corresponds to this output.
Not sure what youâre seeing in this, but I hope it makes sense to you.
ps does it also mean that Iâll need to create for each light a seperate âlightcontrollerv2â? That the lights itself will not be controlled directly?
You can see in this JSON you have 1 subcontrol of ColorPickerV2 type. It has UUID of 14a0bce4-00fa-bd24-ffff13887f83ecc5/AI1. You can control the corresponding RGB light by sending HSB commands to the channel 14a0bce4-00fa-bd24-ffff13887f83ecc5-AI1. It will also accept on, off and Increase, Decrease, Percent and Number for brightness levels.
If you want more lights, you can connect them to the same controller, different outputs. Controller can be used to set and change scenes using all the lights. I donât know if you can have RGB light as a standalone light without the controller, you need to consult Loxone documentation.
Works great!!!
At least what I can see over cameraâs to the remote site.
Just with following item:
Color ZD_L_SalonC "Salontafel" <light> {channel="loxone:miniserver:99d7bd282f:14A0BCE4-00FA-BD24-FFFF13887F83ECC5-AI1"}
In the sitemap 1 line:
Colorpicker item=ZD_L_SalonC
And in the logs when you play with some colors. Also the dimmer and ON/OFF (arrow UP/Down) is working.
2021-03-09 18:56:27.786 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'ZD_L_SalonC' received command 301,95,100
2021-03-09 18:56:27.790 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'ZD_L_SalonC' predicted to become 301,95,100
2021-03-09 18:56:27.792 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ZD_L_SalonC' changed from 359,95,100 to 301,95,100
2021-03-09 18:56:31.312 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'ZD_L_SalonC' received command 246,94,100
2021-03-09 18:56:31.316 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'ZD_L_SalonC' predicted to become 246,94,100
2021-03-09 18:56:31.318 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ZD_L_SalonC' changed from 301,95,100 to 246,94,100
I was already trying to create rules to convert RGB to HSB and so on. But seems it works just with 2 rules. As long as youâve got the correct channel, and config in Loxone⊠Maybe a nice addition to the binding manual could be some basic things you need in the loxone app, and how to find the correct channel ID?
I am glad you got this working. The way this needs to be programmed is a consequence of how this is designed by Loxone. This is described in their documentation.
Hi There, maybe an easy question, but i cant find a solution yet.
i just implemented Openhab 3 with a fresh installation of Openhabian.
I use openhab right now just to connect 3rd Party systems to loxone. GUI will come later on.
I have connected some shellies to openhab with the shelly binding. Everything is working fine there. I can switch the relais and see the power consumption in Openhab
The connection to loxone with the loxone binding works as well . so i can control the light from loxone and openhab.
My last goal is now to take the power consumption from the shelly and push it with openhab to a loxone virtual input as status information.
For this i create a virtual Input in Loxone (analogue value, visible) and connected it with the channel from shelly (Loxone Channel is set to profile: Follow)
As long the virtual input is configured without âonly status viewâ i can see the power consumption.
But this doenst make sense, cause i can then change the forwarded value in Loxone UI.
For Example: Openhab reports to Loxone 9,2 Watts and i have a up/down Button in Loxone GUI to raise it zu 10.2 Watts.
For this i want to set the setting âonly Status Viewâ so the value is just displayed and cant be changed in Loxone.
But as soon this setting is set, the value of power Consumption isnt visible to Loxone anymore, cause the channel is then read only
For the Miniserver Loxone app and OH binding are just some clients which access the API. Both use the same method for talking to the Miniserver. As long as you make something writable and it gets exposed over API (Loxone calls it visible in the UI), this will be visible to both Loxone app and OH. However, I have some ideas to try.
First maybe it is possible to assign different rights to different users? I have never played with users in Loxone. Multiple users with separate rights to different controls are not supported by the binding today. But maybe it is enough to use just one user for oh and another for the app?
Second idea is to have Miniserver poll the value so it is not pushed but pulled. It should be possible with HTTP query, I know it is possible to run HTTP get on Miniserver and read some values this way, not sure how to expose the value in OH, maybe a simple REST API request will do the job.
thx for your quick reply and your suggestions.
i will do some more tests about permissions.
Before Openhab i used Loxberry. i dont know how they do it but they are able to write to an Item in Loxone even it is not visible. but thats not the problem.
Because openhab offers more possiblilities i try to port everything
With that solution (Loxberry) i was able to write to a virtual input (Only Status View). For this i am wondering why the channel on OH is read only ?
Cause a Read Only Input doesnt make sense, cause it is always 0, or i missed something ?
You cant set in in loxone and you cant set it from external (OH)
i tried it even with an âmerkerâ / marker but even here always 0
I donât know the point for âshow status onlyâ virtual inputs, i.e. how their value can be set. I tested setting it for various types of the virtual input. I notice the following behavior:
when show status only is OFF, virtual inputs are exported (in LoxAPP3.json) as corresponding functional blocks, like Switch or Slider. Such blocks accept commands.
when show status only is ON, virtual inputs are always exported as InfoOnlyAnalog functional block. This block (according to the API documentation) does not accept any commands. So there is no way to set its value.
Are you absolutely sure that Loxberry allows for setting VI value even when show status only = ON ? If yes, this would mean it does it in some undocumented way. We would need to research how it works.
I made an experiment to send command to the InfoOnlyAnalog block and it is possible! This is contrary to what API documentation suggests.
So we have two options to support it:
change the VI read-only channels to read-write and allow changing its value
add second channel that is writable
I think option 2 may be better, because we will still retain ability to present VI read-only values if we want to and we would allow setting the value through another channel. But maybe this is not needed and option 1 will be enough? Suggestions?
At first let me say thanks to all your efforts on that binding.
Yes I am sure. I used it for years.
Still have some old Inputs what are configured like this. I just overwritten my old SD card with loxberry image with the openhab implementatio.
I am sure they are using a different way, cause the object even doesnât need to be visible to be accessed by Loxberry.
For example: there is a Mqtt package as well. They implemented a mechanism that I just need to add a virtual input (hidden, Status only) with the name of the Mqtt topic and the data was available to Loxone.
Is it possible that you can set the virtual input by Using Tcp/UdP commands?
At the moment I canât think of all possible problems what could occur.
Would be fantastic if there would be any chance.
Doesnât matter if option one or two.
With the second option it is easier to revert to the current state I think.
And maybe already implemented solutions arenât effected by the change.
I am really totally new to openhab. Maybe other Loxone User have an Opinion to this as well
When Loxberry allows operating blocks which are not visible in the UI, does it recognize such blocks and presents them? Or you need to manually tell it what they are. Do you know if there is source code available for Loxberry?
There is no such automatism like in openhab.
You have do it manually
You have to create an input or output object with the right name. And if you have configured right (for example digital /analoge), you get the value. Otherwise nothing happen s.
For example if you have 50 mqtt topics and have just three objects in Loxone, 47update request go to dev null.
All add-ons and even loxberry itself is in github
I like the way you can configure everything in openhab. To have thing, items and channels.
And to have this automatic detection of everything in it
Hi Pawel,
will you publish the new functionality to be able to write to a virtual input (status only) on Loxone like you suggested and tested before ?
dont understand why loxone publish it to be read only, cause virtual input means you want to input data from a source what is processed in the logic of loxone, without having the posibility to change it in the gui of the app.
for example:
you get a virtual state from a shelly door and window sensor, you want to forward it to loxone.
it doesnt make sense to have a switch in the gui where you can say Window open.
This information comes for example from Openhab what forwards the info the the virtual inpute state.
The virtual info is status only because it just show the state of the external information in the loxone app
It is Readonly in meaning of changing values in Loxone GUI, not in getting values in general
So later on, Iâll test if all works as expected (in combination with hardware swichtes in the room and so).
