Nach Update auf OH4.1.1 - Fehlermeldungen beim Start von OH

[TomW80]

Hallo,

durch das Update von openhab 3.4.5 auf Version 4.1.1 tauchen bei mir beim Start von openhab nun die folgenden Fehler auf:

2024-02-26 18:13:49.917 [INFO ] [el.core.internal.ModelRepositoryImpl] - Validation issues found in configuration model 'fenster.rules', using it anyway:
There is no context to infer the closure's argument types from. Consider typing the arguments or put the closures into a typed context.
There is no context to infer the closure's argument types from. Consider typing the arguments or put the closures into a typed context.
There is no context to infer the closure's argument types from. Consider typing the arguments or put the closures into a typed context.
There is no context to infer the closure's argument types from. Consider typing the arguments or put the closures into a typed context.

Diesen Fehler habe ich in mehreren rules. Was bedeutet dieser genau?
Hier mal die fenster.rules

Code: Alles auswählen

rule "geöffnete Fenster zählen"
when 
    Member of gKontakte changed or
    Item KG_Kellerfenster changed
then

    if (kontakteoffen.state == NULL) 
    {
        kontakteoffen.postUpdate(0)
    }

    var nAnz = gKontakte.members.filter[i|i instanceof ContactItem ].filter[ s|s.state==OPEN].size
    nAnz = nAnz + gKontakte.members.filter[i|i instanceof SwitchItem ].filter[ s|s.state==ON].size

    kontakteoffen.postUpdate( nAnz )
end

Auch dieser Fehler taucht häufig auf.

2024-02-20 02:26:55.372 [INFO ] [al.channel.GroupAddressConfiguration] - Item with mainGA 2/3/131 has more than one GA configured for read at startup, check configuration
2024-02-20 02:26:55.381 [INFO ] [al.channel.GroupAddressConfiguration] - Item with mainGA 2/2/131 has more than one GA configured for read at startup, check configuration
2024-02-20 02:26:55.385 [INFO ] [al.channel.GroupAddressConfiguration] - Item with mainGA 2/3/132 has more than one GA configured for read at startup, check configuration
2024-02-20 02:26:55.395 [INFO ] [al.channel.GroupAddressConfiguration] - Item with mainGA 2/2/132 has more than one GA configured for read at startup, check configuration

So sieht das thing dazu aus. Ist das so falsch, darf ich nur eine GA angeben?

Code: Alles auswählen

    Thing device Jalousieaktor_D10 "Jalousieaktor D10" @ "Technikraum" [
        address="1.1.57",
        fetch=false,
        pingInterval=300,
        readInterval=0
    ] {
        //A
         Type rollershutter : ChannelA                 "Rollo Kind 1 Westen 13M1"            [ upDown="2/2/131+<2/0/0+<2/0/2+<2/0/5+<2/2/130", stopMove="2/3/131+<2/1/0+<2/1/2+<2/1/5+<2/3/130", position="2/4/23+<2/7/25" ] 
        //B         
         Type rollershutter : ChannelB                 "Rollo Kind 1 Süden 13M2"             [ upDown="2/2/132+<2/0/0+<2/0/2+<2/0/6+<2/2/130", stopMove="2/3/132+<2/1/0+<2/1/2+<2/1/6+<2/3/130", position="2/4/24+<2/7/26" ]         
        //C                
         // Frei
        //D
         // Frei
      }

Habe die GAs soweit ich mich noch erinnern kann, so aus der ETS übernommen.

Mehrfach habe ich auch Fehlermeldungen wie diese hier:

2024-02-20 02:26:55.516 [WARN ] [ding.knx.internal.channel.KNXChannel] - Configured DPT '1.002' is incompatible with accepted types '[class org.openhab.core.library.types.DecimalType, class org.openhab.core.library.types.QuantityType]' for channel 'knx:device:42a36ac8:Heizung:DP007'
2024-02-20 02:26:55.518 [WARN ] [ding.knx.internal.channel.KNXChannel] - Configured DPT '1.002' is incompatible with accepted types '[class org.openhab.core.library.types.DecimalType, class org.openhab.core.library.types.QuantityType]' for channel 'knx:device:42a36ac8:Heizung:DP008'
2024-02-20 02:26:55.520 [WARN ] [ding.knx.internal.channel.KNXChannel] - Configured DPT '1.002' is incompatible with accepted types '[class org.openhab.core.library.types.DecimalType, class org.openhab.core.library.types.QuantityType]' for channel 'knx:device:42a36ac8:Heizung:DP009'

So habe ich das im entsprechenden thing definiert.

Code: Alles auswählen

Type number          : DP007                        "Heizkreis 1 - Betriebswahl Heizung - Status (Standby)"             [ ga="1.002:4/6/6" ]
Type number          : DP008                        "Heizkreis 1 - Betriebswahl Heizung - Status (Woche 1)"             [ ga="1.002:4/6/7" ]
Type number          : DP009                        "Heizkreis 1 - Betriebswahl Heizung - Status (Woche 2)"             [ ga="1.002:4/6/8" ]
Type number          : DP010                        "Heizkreis 1 - Betriebswahl Heizung - Status (Konstant)"            [ ga="1.002:4/6/9" ]
Type number          : DP011                        "Heizkreis 1 - Betriebswahl Heizung - Status (Sparbetrieb)"         [ ga="1.002:4/6/10" ]

Laut der Datenpunktliste von Hoval passt das auch so.

Screenshot 2024-02-26 171551.png

Teilweise taucht auch diese Meldung auf:

2024-02-20 02:26:55.709 [WARN ] [al.channel.GroupAddressConfiguration] - Failed parsing channel configuration ''.

Jemand eine Idee wie ich die Fehler weg bekomme?

Gruß Tom

[udo1toni]

Also dieser Fehler:

Code: Alles auswählen

Item with mainGA ... has more than one GA configured for read at startup, check configuration

ist sehr eindeutig und Deine Konfiguration ist an dieser Stelle schlicht falsch.
Es geht hier ausdrücklich um den Read Request, der bei Systemstart für jede GA gesendet wird, der ein < vorangestellt ist. Die Idee hinter den Read Requests ist, dass knx dadurch direkt beim Systemstart den korrekten Status jedes Channels ermitteln kann.
Aber: Ein Channel kann nur einen Status übermitteln. Z.B. kann ein Rollladen nicht gleichzeitig mehrere Positionen einnehmen. Und es gibt auch pro Channel (eigentlich ja sogar Item) nur eine einzige "echte" Quelle für den Status. Bei einem Rollladen wäre das der position Parameter. Falls ein rollershutter Channel keine absolute Positionierung beherrscht, kann man als (schlechten) Ersatz auch die upDown Information nutzen, ABER definitiv nur von einem einzigen KO, und das ist die entsprechende Statusmeldung des Rollladenaktors. Und selbst wenn in der ETS hier mehrere GA eingetragen sein sollten (was bei einem Status KO sinnlos ist), wäre wegen der grundlegenden knx "Gesetze" nur die erste angegebene GA sendend, und egal auf welcher verknüpften GA ein Read Request im KO ankommt, das KO wird immer und ausschließlich auf der ersten GA antworten (immer vorausgesetzt, dass das KO überhaupt auf Read Requests antwortet).
Im Normalfall wird pro Parameter genau eine GA angegeben, wenn der Parameter auch den Status liefert wird eine zweite GA angegeben, falls diese von der ersten GA abweicht.

Beispiel: Ein Dimmer hat diverse KO, unter anderem ein KO ON/OFF Status, ein KO ON/OFF Befehl, ein KO Dimmlevel Status, ein KO Dimmlevel Befehl und ein KO relatives Dimmen Befehl (hinzu kommen vielleicht noch weitere für Zwangssteuerung und Szenen)
Für openHAB sind nur drei KO interessant, nämlich ON/OFF Befehl sowie Dimmlevel Befehl und Status. Der ON/OFF Befehl ist auch nur deshalb interessant, weil man dadurch von openHAB aus den Dimmer auf den Default Einschaltlevel dimmen kann, ohne diesen explizit zu kennen, ansonsten könnte man auch komplett auf den Parameter switch verzichten. openHAB steuert Dimmer gewöhnlich immer absolut, also über einen Prozentwert und die Rückmeldung des Zustands erfolgt ebenfalls als Prozentwert, also insgesamt drei GA. Wenn in den Dimmer KO noch weitere GA angegeben sind, ist das für openHAB unerheblich, da dank der Status-GA immer der gültige Status in openHAB bekannt ist; man muss also nicht zwingend jeden Befehl mithören (und spätestens mit Szenensteuerungen gibt es auch gar keinen zwingenden Zusammenhang zwischen empfangenen Befehlen und daraus resultierenden Status)
Das gleiche gilt uneingeschränkt für alle anderen Arten von Aktoren, seien es Relais für Licht/Steckdosen usw., Rollläden, Heizungssteuerungen...
Und wenn wir zu Sensoren kommen (also z.B. Temperatursensoren oder auch Bewegungsmelder) so gibt es überhaupt nur eine einzige GA, die dann evtl. auch lesbar ist.

Auch diese Meldung ist eindeutig:

Code: Alles auswählen

Configured DPT '1.002' is incompatible with accepted types '[class org.openhab.core.library.types.DecimalType, class org.openhab.core.library.types.QuantityType]' for channel ...

Du hast den Channel als number Channel definiert, gibst aber einen DPT1.x an. DPT1 ist ein Bit und 1.002 per Definition Boolean true/false, was nun mal keine gültige Zahl ist.
Ausweg: nutze stattdessen einen switch Channel, wie es sich gehört oder wenn es unbedingt 0/1 sein muss, kannst Du DPT 1.022 angeben, das ist der einzige 1er-DPT, der als DecimalType interpretierbar ist.

Noch ein allgemeiner Hinweis zu den DPT: Im DPT sind verschiedene Informationen kodiert, zum einen die Breite des Datums, also z.B. 1 Bit, 2 Bit, 4 Bit, 2 Byte usw., das geht aus dem Haupt-DPT hervor (links vom Punkt...) außerdem gibt es verschiedene Formate, z.B. kann ein 4-Byte Wert ein Big Integer sein oder auch ein Float Value, die Mantisse kann unterschiedlich groß sein, der Wert kann vorzeichenbehaftet sein oder eben nicht usw. Auch das ist im Haupt-DPT kodiert. Im Neben-DPT (rechts vom Punkt...) sind hingegen Informationen hinterlegt, wie der Wert zu interpretieren ist. Diese Information ist natürlich abhängig vom Haupt-DPT
Und erschwerend kommt nun hinzu, dass im knx Protokoll nichts dazu mit übertragen wird - das hängt schlicht damit zusammen, dass das Protokoll auf Effizienz ausgelegt ist. Der Bus läuft mit 9600 Bit/s und ein Datentelegramm muss ohnehin schon viel Ballast mit schleppen - die 16 Bit GA, die 16 Bit physikalische Quelladresse, einen Rundenzähler, die Daten selbst, sowie natürlich Prüfsummen. Die verknüpften KO haben ohnehin immer ein fixes Format, die DPT Informationen sind also nur für Visualisierungen wichtig.
Das bedeutet für openHAB: Wenn ein DPT angegeben werden muss, dann gewöhnlich nur bei number Channels, und dort meist, um die korrekte QuantityType Zuordnung vorzunehmen oder die Enkodierung des Wertes (Float,Integer usw.) zu definieren. Bei Bit-Informationen ist es hingegen "witzlos" den DPT zu setzen, denn aus openHAB-Sicht ist das Bit ein Bit. Es wird entweder als ON/OFF (switch) oder als OPEN/CLOSED (contact) interpretiert, andere Formate sind nicht vorgesehen.

Übrigens gibt es in der openHAB knx Doku jetzt ganz neu (für den OH4.2-Zweig, gilt aber uneingeschränkt auch für die aktuelle Version) eine vollständige Liste aller unterstützten DPT, das heißt ich muss nicht mehr auf den Source Code verweisen, Juhu

Code: Alles auswählen

Failed parsing channel configuration

Mutmaßlich weitere Fehler, oder aber die Menge an vorhergehenden Verstößen führt dazu, dass openHAB keine korrekte Konfiguration bestimmen kann.

Bleibt noch der erste Fehler:

Code: Alles auswählen

There is no context to infer the closure's argument types from. Consider typing the arguments or put the closures into a typed context.

Auch hier kann ich nur Mutmaßungen anstellen. Mein Tipp wäre, in diesem Fall die Variable vom Typ festzulegen, bevorzugt als Integer, also so:

Code: Alles auswählen

var Integer nAnz = ...

[TomW80]

Hallo Udo,

Wow, vielen Dank für die sehr ausführliche Antwort!
Ich werde das nächste Woche bei mir alles anpassen, früher werde ich leider nicht dazukommen.

Melde mich dann nochmal.

Gruß Tom

[TomW80]

Auch diese Meldung ist eindeutig:

Code: Alles auswählen

Configured DPT '1.002' is incompatible with accepted types '[class org.openhab.core.library.types.DecimalType, class org.openhab.core.library.types.QuantityType]' for channel ...

Du hast den Channel als number Channel definiert, gibst aber einen DPT1.x an. DPT1 ist ein Bit und 1.002 per Definition Boolean true/false, was nun mal keine gültige Zahl ist.
Ausweg: nutze stattdessen einen switch Channel, wie es sich gehört oder wenn es unbedingt 0/1 sein muss, kannst Du DPT 1.022 angeben, das ist der einzige 1er-DPT, der als DecimalType interpretierbar ist.

Ich habe das jetzt auf Switch Channel geändert,

Code: Alles auswählen

knx.things
Type switch          : DP007                        "Heizkreis 1 - Betriebswahl Heizung - Status (Standby)"             [ ga="1.002:4/6/6" ]
Type switch          : DP008                        "Heizkreis 1 - Betriebswahl Heizung - Status (Woche 1)"             [ ga="1.002:4/6/7" ]
Type switch          : DP009                        "Heizkreis 1 - Betriebswahl Heizung - Status (Woche 2)"             [ ga="1.002:4/6/8" ]
Type switch          : DP010                        "Heizkreis 1 - Betriebswahl Heizung - Status (Konstant)"            [ ga="1.002:4/6/9" ]
Type switch          : DP011                        "Heizkreis 1 - Betriebswahl Heizung - Status (Sparbetrieb)"         [ ga="1.002:4/6/10" ]

tj.items
Switch   HeizungDP007_11   "Heizung Status (Standby) [MAP(heizung.map):%s]"           (gHeizungStatus)  {channel="knx:device:42a36ac8:Heizung:DP007"}
Switch   HeizungDP008_12   "Heizung Status (Woche 1) [MAP(heizung.map):%s]"           (gHeizungStatus)  {channel="knx:device:42a36ac8:Heizung:DP008"}
Switch   HeizungDP009_13   "Heizung Status (Woche 2) [MAP(heizung.map):%s]"           (gHeizungStatus)  {channel="knx:device:42a36ac8:Heizung:DP009"}
Switch   HeizungDP010_14   "Heizung Status (Konstant) [MAP(heizung.map):%s]"          (gHeizungStatus)  {channel="knx:device:42a36ac8:Heizung:DP010"}
Switch   HeizungDP011_15   "Heizung Status (Sparbetrieb) [MAP(heizung.map):%s]"       (gHeizungStatus)  {channel="knx:device:42a36ac8:Heizung:DP011"}

Aber ich erhalte jetzt folgenden Fehler:

2024-03-05 02:24:52.293 [ERROR] [org.openhab.core.items.GenericItem ] - Tried to set invalid state 0 (DecimalType) on item HeizungDP009_13 of type SwitchItem, ignoring it
2024-03-05 02:24:52.617 [ERROR] [org.openhab.core.items.GenericItem ] - Tried to set invalid state 0 (DecimalType) on item HeizungDP010_14 of type SwitchItem, ignoring it

Aber warum auch nur bei diesen beiden, die anderen im Beispiel oben meckern nicht.
Wenn ich mir die Werte der Items anschaue, habe diese beiden NULL der Rest hat ON oder OFF.

Oder soll ich doch lieber DPT 1.022 angeben?

Bleibt noch der erste Fehler:

Code: Alles auswählen

There is no context to infer the closure's argument types from. Consider typing the arguments or put the closures into a typed context.

Auch hier kann ich nur Mutmaßungen anstellen. Mein Tipp wäre, in diesem Fall die Variable vom Typ festzulegen, bevorzugt als Integer, also so:

Code: Alles auswählen

var Integer nAnz = ...

Habe ich gemacht, Fehlermeldung besteht aber weiterhin.

[udo1toni]

Ich schätze, da werden noch weitere Fehler irgendwo in Deinen Rules schlummern. Was ist denn der Inhalt von heizung.map?

[TomW80]

Ich schätze, da werden noch weitere Fehler irgendwo in Deinen Rules schlummern. Was ist denn der Inhalt von heizung.map?

Code: Alles auswählen

1=Aktiv
1.0=Aktiv
ON=Aktiv
0=Inaktiv
0.0=Inaktiv
OFF=Inaktiv
11=Standby
12=Woche 1
13=Woche 2
14=Konstant
15=Sparbetrieb
21=heizen
22=kühlen
23=störung
NULL=undefiniert
-=undefiniert

Ich habe jetzt mal über den Gruppenmonitor der ETS die GA gelesen. Nach einem erneuten Neustart von openhab trat der Fehler nicht auf. Werde das die Tage mal beobachten und dann nochmal einen Neustart machen.

[udo1toni]

Kann auch gut sein, dass da noch ein Rest der alten Konfiguration im Cache hing, was dann mit dem Neustart gelöst wurde.

[TomW80]

Die Fehler sind bis auf diesen (in mehreren Rules) hier alle weg.

2024-02-26 18:13:49.917 [INFO ] [el.core.internal.ModelRepositoryImpl] - Validation issues found in configuration model 'fenster.rules', using it anyway:
There is no context to infer the closure's argument types from. Consider typing the arguments or put the closures into a typed context.
There is no context to infer the closure's argument types from. Consider typing the arguments or put the closures into a typed context.
There is no context to infer the closure's argument types from. Consider typing the arguments or put the closures into a typed context.
There is no context to infer the closure's argument types from. Consider typing the arguments or put the closures into a typed context.

Hat da noch jemand eine Idee?