KNX: OH2 does not recognise updates of Elsner Suntracer KNX sl light Blocking Objects

Add-ons Bindings
1

I have an interesting behaviour with Elsner Suntracer KNX sl light Blocking Objects and OpenHAB2 observed. Not sure whether anyone of you saw the same, and whether you found a good way to resolve it.

My Intention: For times away, i programmed on the KNX bus leveraging Suntracer logic functions some behaviours for automated up and down for rollershutter. This works perfectly fine. However, when I am at home, I do not want this automation. In order to block it, I leverage the Suntracer blocking (Sperren) objects.

On the KNX Bus, this works perfectly fine. I I leverage ETS, than I can set the status of the block objects, and put it to ON / OFF. Perfect. Also, when I leverage ETS to change the status of the block objects, than OH2 updates the status immediately.

If i however put the status to ON/OFF leveraging OH, than it does not update the status. This is really strange and to me it seems an OH2 Issue.

Note: Other than for example MDT switches, Elsner Suntracer does not offer a status object for the blocking switch, however, it can be configured to announce the current status which again it does on the KNX bus, but OH2 is not reading it

Example 1:
KNX.things

Type switch             : Wetterstation_AutomationJalousien_Wohzimmer_Regen_sperren      "Wetterstaion Automation Jalousien bei Regen deaktivieren"    [ ga="<3/6/5" ]

knx.items

Switch Wetterstation_AutomationJalousien_Wohzimmer_Regen_sperren            "Wetterstaion Automation Jalousien bei Regen deaktivieren [MAP(Wetterstation_AutomationJalousien_Wohzimmer_Regen_sperren.map):%s]"  <switch>             (All, gUG_Garage, gWetter, gSQLAllChanges)  	        { channel="knx:device:bridge:generic:Wetterstation_AutomationJalousien_Wohzimmer_Regen_sperren" }

knx.sitemap

Switch item=Wetterstation_AutomationJalousien_Wohzimmer_Regen_sperren

Example 2:
knx.things:

Type switch             : Wetterstation_Hitzeschutz25Grad_Wohnzimmer_sperren             "Wetterstaion Hitzeschutz ab 25 °C daktivieren"               [ ga="<3/7/3" ]

knx.items:

Switch Wetterstation_Hitzeschutz25Grad_Wohnzimmer_sperren                   "Wetterstaion Hitzeschutz ab 25 °C Wohnzimmer deaktivieren"                                                                                             (All, gWetter, gSQLAllChangesRestoreOnStartup)          { channel="knx:device:bridge:generic:Wetterstation_Hitzeschutz25Grad_Wohnzimmer_sperren" }

knx.sitemap:

Switch item=Wetterstation_Hitzeschutz25Grad_Wohnzimmer_sperren

jdbc.persist:


Strategies {
        everyMinute	: "0 * * * * ?"
        every15min	: "0 */15 * * * ?"
        everyHour       : "0 0 * * * ?"
        everyDay        : "0 0 0 * * ?"
        every15min	: "0 */15 * * * ?"

        // if no strategy is specified for an Item entry below, the default list will be used
       default = everyChange
}

Items {

        // 
        // Items Configuration Section 
                gSQL* : strategy = every15min, everyHour, everyDay
                gSQLAllChanges* : strategy = everyChange
                gSQLAllChangesRestoreOnStartup* : strategy = everyChange, every15min, everyHour, everyDay, restoreOnStartup
                gSQLRestoreTemperature* : strategy = everyChange, restoreOnStartup
        // Items Configuration für Rules
                Wetterstation_Regen_15min :strategy = every15min
                comfoairTemps_Chart : strategy = everyChange, restoreOnStartup
	        comfoairEfficiency : strategy = everyMinute, restoreOnStartup
	        comfoairFanLevel : strategy = everyMinute, restoreOnStartup

}
2

As it’s an Input, you can’t read the status of this switch, so please delete the < in the channel definition.
Maybe you’ll have to provide the DPT to openHAB (well, no, should not be necessary…)

3

Thanks. I did delete the < . However, no change. If I like to turn on (ON) the switch, it immediately jumps back to OFF.

If however I read the status with ETS, it would show ON/OFF. It seems OH2 does not read the status from the bus.

4

No, openHAB can’t read the status, as elsner does not provide the status.
openHAB should update the status according to the sent command, so if switching to ON, openHAB should postUpdate the item to ON.
Maybe there’s something in the logs?

5

I talked to Elsner support. The following is key to make the Weatherstation reacting on what was sent by OH2:

  • Set the L Ü and S flags.

Once set, you can send via OH2 on / off and the weather station reacts. I have tested this and this works.

However, still OH2 does not update the status. This means:

  • If you leverage the OH2 switch to send ON, the ON arrives on the KNX bus and the weatherstation sets the object to ON. The OpenHAB Switch however jumps back to OFF. It remains OFF up until you leverage ETS and read the status. It would respond ON. From this moment, OH changes to ON because OH reads from the bus the ON value that was sent.
  • If you leverage the OH2 switch to send OFF, the OFF arrives on the KNX bus and the weatherstation sets the object to OFF. The OpenHAB switch however jumps back to ON. It remains ON up until you leverage ETS and read the status. It would respond OFF. From this moment, OH changes to OFF. Because OH reads from the bus the OFF value that was sent.

My conclusion, OH sends the right comment, the right comment arrives on the bus and the weatherstation reacts correctly. However, OH does lose the status sent and/or OH is unable to read the status from a group in the bus automatically. You have to force this by leveraging ETS and reading the status of the group. I think this is strange.

6

Well, I’ve never seen this bahavior. In fact, the only situation I can guess is an autoupdate=“false” setting, but I can’t see this option in your knx.items. Please try an explicit autoupdate=“true”

Switch Wetterstation_AutomationJalousien_Wohzimmer_Regen_sperren "Wetterstaion Automation Jalousien bei Regen deaktivieren [MAP(Wetterstation_AutomationJalousien_Wohzimmer_Regen_sperren.map):%s]" <switch> (All, gUG_Garage, gWetter, gSQLAllChanges) { channel="knx:device:bridge:generic:Wetterstation_AutomationJalousien_Wohzimmer_Regen_sperren" , autoupdate="true" }

Please do not use identical names for channels and items, this tends to make trouble. I doubt that the Label will be displayed correctly in any UI either :wink:

7

Blockquote Please do not use identical names for channels and items, this tends to make trouble.

Sorry to comeback on this months later… What exactly do you mean by this?

8

The Channel is named Wetterstation_AutomationJalousien_Wohzimmer_Regen_sperren and so is the Item.
It’s not that it’s not possible, but it may lead to mistakes.

9

Understood. So you are saying that the channels should be called different then items. Basically, names for KNX devices used in .things need to be different from the names that are used for items in .items and sitemap.

Honestly, i did not know this and it looks i have some re-naming work to do :frowning:

10

No they don’t. But some thoughts about naming:
A channel is part of a thing. In question of knx things, the most common way would be to map a device to a thing. e.g. a 6 channel switch actuator is a thing with 6 channels (if only using basic functions of the actuator) So what you will get is a structure like
knx:device:bridge:my6chSwitchActuator:ch1 to knx:device:bridge:myDevice:ch6. Take a look in the control cabinet, you will see just the device with its six buttons, one for each channel.
As every device in knx has its own individual address (i.e. physikalische Adresse in german) you even can use a thing name like mdt_1_1_45 for a MDT device with individual address 1.1.45. This number should be written right at the actuator.
Each channel has its own label, this can be used for a human readable name like “Regen Sperre”. Be aware that every Thing is listed with this label, not the channel name, e.g. in VSCode thing list. The Label will be used to automatically build the item name. The result will be more readable as the channel UIDs will be much shorter.

On the other hand, the item names should be justified to the precise function, maybe a bit less long, think about the code for getting a Number Item to a variable:

var Number var_Wetterstation_Messdaten_Regen_Regenmenge_Aktuell = if(Wetterstation_Messdaten_Regen_Regenmenge_Aktuell.state instanceof Number) (Wetterstation_Messdaten_Regen_Regenmenge_Aktuell.state as Number) else 0

Yes, you can just read what it’s about, but it’s a looooong line of code.

var Number nRain = if(WSRainNow.state instanceof Number) (WSRainNow.state as Number) else 0 // get current amount of Rain

Much shorter and not less readable. Of course you could use german words, too ;), but the point is, there is much less useless information in the code, even with an additional comment.

11

Thanks a lot Udo, this is very helpful! Trying to apply the above logic (and before i re-write the whole file) things.knx would become like this:

Bridge knx:ip:bridge [ 
    type="TUNNEL",
    ipAddress="10.1.1.2",
    portNumber=3671, 
    readingPause=50, 
    responseTimeout=10, 
    readRetriesLimit=3, 
    autoReconnectPeriod=60 
] {
    Thing device MDT_1_1_31 [
    address="1.1.31"
    ] {
        Type switch         : MDT_1_1_31_ch1_Licht_Technik          "Light"  [ ga="3/0/4+<3/0/5" ]
        Type switch         : MDT_1_1_31_ch2_Licht_Garage           "Light"  [ ga="3/0/5+<3/0/6" ]
        Type switch         : MDT_1_1_31_ch3_Licht_GaragenTor       "Light"  [ ga="3/0/7+<3/0/8" ]
        Type switch         : MDT_1_1_31_ch4_Licht_Waschraum        "Light"  [ ga="3/0/9+<3/0/10"]
        }
    Thing device MDT_1_1_32 [
    address="1.1.32"
    ] {
        Type switch         : MDT_1_1_32_ch1_Licht_Kueche           "Light"  [ ga="3/0/11+<3/0/12" ]
        Type switch         : MDT_1_1_32_ch2_Licht_Kuechentisch     "Light"  [ ga="3/0/13+<3/0/14" ]
        Type switch         : MDT_1_1_32_ch3_Licht_Korridor1        "Light"  [ ga="3/0/15+<3/0/16" ]
        Type switch         : MDT_1_1_32_ch4_Licht_Korridor2        "Light"  [ ga="3/0/17+<3/0/18"]
        }


}
12

No. I prefer it this way:

Bridge knx:ip:bridge [ 
    type="TUNNEL",
    ipAddress="10.1.1.2",
    portNumber=3671, 
    readingPause=50, 
    responseTimeout=10, 
    readRetriesLimit=3, 
    autoReconnectPeriod=60 
] {
    Thing device MDT_1_1_31 "Switch 1" [
        address="1.1.31"
    ] {
        Type switch         : ch1 "Licht Technik"     [ ga="3/0/4+<3/0/5" ]
        Type switch         : ch2 "Licht Garage"      [ ga="3/0/5+<3/0/6" ]
        Type switch         : ch3 "Licht GaragenTor"  [ ga="3/0/7+<3/0/8" ]
        Type switch         : ch4 "Licht Waschraum"   [ ga="3/0/9+<3/0/10" ]
        }
    Thing device MDT_1_1_32 "Switch 2" [
        address="1.1.32"
    ] {
        Type switch         : ch1 "Licht Küche"       [ ga="3/0/11+<3/0/12" ]
        Type switch         : ch2 "Licht Küchentisch" [ ga="3/0/13+<3/0/14" ]
        Type switch         : ch3 "Licht Korridor 1"  [ ga="3/0/15+<3/0/16" ]
        Type switch         : ch4 "Licht Korridor 2"  [ ga="3/0/17+<3/0/18" ]
        }
}

This will result in Items like this:

Switch Switch_1_ch1 "Licht Technik"     { channel="knx:device:bridge:MDT_1_1_31:ch1" }
Switch Switch_1_ch2 "Licht Garage"      { channel="knx:device:bridge:MDT_1_1_31:ch2" }
Switch Switch_1_ch3 "Licht GaragenTor"  { channel="knx:device:bridge:MDT_1_1_31:ch3" }
Switch Switch_1_ch4 "Licht Waschraum"   { channel="knx:device:bridge:MDT_1_1_31:ch4" }

Switch Switch_2_ch1 "Licht Küche"       { channel="knx:device:bridge:MDT_1_1_32:ch1" }
Switch Switch_2_ch2 "Licht Küchentisch" { channel="knx:device:bridge:MDT_1_1_32:ch2" }
Switch Switch_2_ch3 "Licht Korridor 1"  { channel="knx:device:bridge:MDT_1_1_32:ch3" }
Switch Switch_2_ch4 "Licht Korridor 2"  { channel="knx:device:bridge:MDT_1_1_32:ch4" }

And of course you can always change Item names and labels.