33_readingsGroup, Attribut sortColumn, Darstellungsfehler odd:even Table

Begonnen von HomeAuto_User, 20 Februar 2020, 23:43:04

Vorheriges Thema - Nächstes Thema

HomeAuto_User

Hallo,
ich besitze eine einfache Readingsgroup.
Wenn man das Attribut sortColumn auf den Wert 2 oder 4 stellt, so stimmt die odd:even Zuteilung nicht mehr.
Es gibt einige Zeilen welche durchgehend "einfarbig" sind und dann auf einmal die andere "Formatierung" geift.
Stelle ich den Wert des Attributes auf 1 Bsp, so ist es richtig abwechselnd odd und even.

Internals:
   DEF        <Sensor>,<letzter Empfang>,<RSSI>,<Zustand>,<Bat>
TYPE=CUL_FHTTK:LastActionTime,+CUL_868Mhz_RSSI,state,batteryState
   FUUID      5c44efcb-f33f-08a5-0fc3-81315ad6702398c3
   NAME       FS20_FHTTK
   NR         229
   NTFY_ORDER 50-FS20_FHTTK
   STATE      Initialized
   TYPE       readingsGroup
   changed    0
   mayBeVisible 1
   CONTENT:
     CUL_FHTTK_195b30 1
     CUL_FHTTK_66e5dc 1
     CUL_FHTTK_81460e 1
     CUL_FHTTK_8ee4f9 1
     CUL_FHTTK_eea27f 1
     CUL_FHTTK_ef953e 1
   CONTENT2:
   DEVICES:
     ARRAY(0x6beecc8)
     ARRAY(0x7228df0)
     ARRAY(0x6c3e528)
     ARRAY(0x6999018)
     ARRAY(0x6bf66d8)
     ARRAY(0x7055e70)
     ARRAY(0x70c8168)
   fhem:
     lastDefChange 13
     last_update 1582238095.41965
   helper:
     DEF       
     nameStyle  style="text-align:left; color:blue; padding: 0px 8px 0px 8px;"
     positions:
       CUL_FHTTK_195b30.CUL_868Mhz_RSSI 2:2
       CUL_FHTTK_195b30.LastActionTime 2:1
       CUL_FHTTK_195b30.batteryState 2:4
       CUL_FHTTK_195b30.state 2:3
       CUL_FHTTK_66e5dc.LastActionTime 3:1
       CUL_FHTTK_66e5dc.batteryState 3:3
       CUL_FHTTK_66e5dc.state 3:2
       CUL_FHTTK_81460e.CUL_868Mhz_RSSI 4:2
       CUL_FHTTK_81460e.LastActionTime 4:1
       CUL_FHTTK_81460e.batteryState 4:4
       CUL_FHTTK_81460e.state 4:3
       CUL_FHTTK_8ee4f9.CUL_868Mhz_RSSI 5:2
       CUL_FHTTK_8ee4f9.LastActionTime 5:1
       CUL_FHTTK_8ee4f9.batteryState 5:4
       CUL_FHTTK_8ee4f9.state 5:3
       CUL_FHTTK_eea27f.CUL_868Mhz_RSSI 6:2
       CUL_FHTTK_eea27f.LastActionTime 6:1
       CUL_FHTTK_eea27f.batteryState 6:4
       CUL_FHTTK_eea27f.state 6:3
       CUL_FHTTK_ef953e.CUL_868Mhz_RSSI 7:2
       CUL_FHTTK_ef953e.LastActionTime 7:1
       CUL_FHTTK_ef953e.batteryState 7:4
       CUL_FHTTK_ef953e.state 7:3
     recalc:
       undef
       ARRAY(0x6c166e0)
       undef
       ARRAY(0x3b20508)
       ARRAY(0x7137b08)
     values:
       formated:
         undef
         ARRAY(0x6c3a570)
         ARRAY(0x6be4e38)
         ARRAY(0x3bc7530)
         ARRAY(0x6ca6e08)
       orig:
         undef
         ARRAY(0x70dff88)
         ARRAY(0x6c31060)
         ARRAY(0x6beafb8)
         ARRAY(0x6c67df0)
       prefixsuffix:
         undef
         ARRAY(0x6c37880)
         ARRAY(0x6beca08)
         ARRAY(0x4bc5110)
         ARRAY(0x6c52ed8)
Attributes:
   nameStyle  style="text-align:left; color:blue; padding: 0px 8px 0px 8px;"
   room       08_Tabellen
   sortColumn 2
   style      style="text-align:center;"


MfG
"Developer" heißt nicht, das man alles wissen kann!
- FHEM v5.9 | Rasberry PI 3
- radino CC1101 433Mhz (SIGNALduino)| - radino CC1101 868Mhz (CUL) | nano 433Mhz (SIGNALduino) - Sensoren: purer Dschungel querbeet

mumpitzstuff

Liegts vielleicht nur an dem Testkontakt? Erzwinge mal eine leere Zelle für RSSI. Ich glaube mit ! war das irgendwie...

HomeAuto_User

Hallo,

Zitat von: mumpitzstuff am 21 Februar 2020, 13:26:55
Liegts vielleicht nur an dem Testkontakt? Erzwinge mal eine leere Zelle für RSSI. Ich glaube mit ! war das irgendwie...

Ich habe es getestet und es liegt nicht daran.
Bei einem anderen Test mit einer neu angelegten Readingsgroup

Internals:
   CFGFN     
   DEF        <Sensor>,<Reading>,<Value>
TYPE=Hideki
   FUUID      5e4fcd8d-f33f-2293-a1a4-78bf256d28a82194
   NAME       Test
   NR         718
   NTFY_ORDER 50-Test
   STATE      Initialized
   TYPE       readingsGroup
   mayBeVisible 1
   CONTENT:
     Hideki_30_1 1
     Hideki_30_2 1
     Hideki_30_3 1
     Hideki_30_4 1
     Hideki_30_5 1
   CONTENT2:
   DEVICES:
     ARRAY(0x4d2ab20)
     ARRAY(0x4d60e28)
     ARRAY(0x4d62830)
     ARRAY(0x521deb8)
     ARRAY(0x28769d8)
     ARRAY(0x4d66820)
   fhem:
     lastDefChange 18
     last_update 1582288546.01353
   helper:
     DEF       
     positions:
       Hideki_30_1.LastActionTime 2:1
       Hideki_30_1.absFeuchte 2:2
       Hideki_30_1.battery 2:3
       Hideki_30_1.batteryState 2:4
       Hideki_30_1.channel 2:5
       Hideki_30_1.comfort_level 2:6
       Hideki_30_1.dewpoint 2:7
       Hideki_30_1.humidity 2:8
       Hideki_30_1.package_number 2:9
       Hideki_30_1.state 2:10
       Hideki_30_1.temperature 2:11
       Hideki_30_2.LastActionTime 3:1
       Hideki_30_2.absFeuchte 3:2
       Hideki_30_2.battery 3:3
       Hideki_30_2.batteryState 3:4
       Hideki_30_2.channel 3:5
       Hideki_30_2.comfort_level 3:6
       Hideki_30_2.dewpoint 3:7
       Hideki_30_2.humidity 3:8
       Hideki_30_2.package_number 3:9
       Hideki_30_2.state 3:10
       Hideki_30_2.temperature 3:11
       Hideki_30_3.LastActionTime 4:1
       Hideki_30_3.absFeuchte 4:2
       Hideki_30_3.battery 4:3
       Hideki_30_3.batteryState 4:4
       Hideki_30_3.channel 4:5
       Hideki_30_3.comfort_level 4:6
       Hideki_30_3.dewpoint 4:7
       Hideki_30_3.humidity 4:8
       Hideki_30_3.package_number 4:9
       Hideki_30_3.state 4:10
       Hideki_30_3.temperature 4:11
       Hideki_30_4.LastActionTime 5:1
       Hideki_30_4.absFeuchte 5:2
       Hideki_30_4.battery 5:3
       Hideki_30_4.batteryState 5:4
       Hideki_30_4.channel 5:5
       Hideki_30_4.comfort_level 5:6
       Hideki_30_4.dewpoint 5:7
       Hideki_30_4.humidity 5:8
       Hideki_30_4.package_number 5:9
       Hideki_30_4.state 5:10
       Hideki_30_4.temperature 5:11
       Hideki_30_5.LastActionTime 6:1
       Hideki_30_5.absFeuchte 6:2
       Hideki_30_5.battery 6:3
       Hideki_30_5.batteryState 6:4
       Hideki_30_5.channel 6:5
       Hideki_30_5.comfort_level 6:6
       Hideki_30_5.dewpoint 6:7
       Hideki_30_5.humidity 6:8
       Hideki_30_5.package_number 6:9
       Hideki_30_5.state 6:10
       Hideki_30_5.temperature 6:11
     recalc:
       undef
       ARRAY(0x4d30b30)
       ARRAY(0x521f330)
       ARRAY(0x1d34180)
       ARRAY(0x4d3fc00)
       ARRAY(0x4db6d00)
       ARRAY(0x527c010)
       ARRAY(0x527d490)
       ARRAY(0x4db07e0)
       ARRAY(0x4d5edc0)
       ARRAY(0x5187980)
       ARRAY(0x4d38e48)
     values:
       formated:
         undef
         ARRAY(0x107d188)
         ARRAY(0x4d75af8)
         ARRAY(0x4d62f08)
         ARRAY(0x4d6f4c0)
         ARRAY(0x2c6d478)
         ARRAY(0x3459818)
         ARRAY(0x5223288)
         ARRAY(0x4daef90)
         ARRAY(0x4d38a88)
         ARRAY(0x5222c88)
         ARRAY(0x4d903e8)
       orig:
         undef
         ARRAY(0x4d85968)
         ARRAY(0x5279850)
         ARRAY(0x527d3e8)
         ARRAY(0x4da1660)
         ARRAY(0x4d18a40)
         ARRAY(0x4d6b278)
         ARRAY(0x4d61ca0)
         ARRAY(0x4d85510)
         ARRAY(0x4d5f608)
         ARRAY(0x4d64368)
         ARRAY(0x4d5e958)
       prefixsuffix:
         undef
         ARRAY(0x518cb70)
         ARRAY(0x4d8e1d0)
         ARRAY(0x4d902e0)
         ARRAY(0x4b0e2b0)
         ARRAY(0x4d523b0)
         ARRAY(0x4d62c98)
         ARRAY(0x4d81c40)
         ARRAY(0x5279ad8)
         ARRAY(0x4bddab8)
         ARRAY(0x4db0c90)
         ARRAY(0x4d67078)
Attributes:
   sortColumn 1


Konnte ich den Fall rekonstruieren.

Ohne das Attribut
sortColumn
ist die Darstellung richtig mit odd:even Abwechslung.
Sobald ich den Attributwert auf 1 setze kommt es zu einer fehlerhaften Darstellung und mit dem Wert 2 oder 3 wird dies noch schlimmer.

Es liegt an der Verarbeitung des Attributes. Anbei 3 Bilder mit den Zuständen.
Hier muss der Maintainer @justme1968 noch einmal drüber schauen.
"Developer" heißt nicht, das man alles wissen kann!
- FHEM v5.9 | Rasberry PI 3
- radino CC1101 433Mhz (SIGNALduino)| - radino CC1101 868Mhz (CUL) | nano 433Mhz (SIGNALduino) - Sensoren: purer Dschungel querbeet

justme1968

das verhalten ist aktuell normal da die even/odd markierung auf perl seite ein mal erzeugt wird und beim umsortieren beibehalten wird.

für die neue commandref implementierung habe ich schon eine lösung wie man auf javascript seite die zeilen neu einfärben kann. man kann das ganze aber auch komplett auf css basis machen. je nach dem welche variante in der commandref landet wird danach readingsGroup und eventuell fhem an sich angepasst.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

ToKa

Hallo justme,

gibt es hier schon etwas Neues? Mein fhem ist aktuell und ich bin auch von dem Problem betroffen...

Beste Grüße
Torsten
RaspberryPi3 mit RaZberry2 und Conbee II
Fibaro: FGWPE/F-101 Switch & FIBARO System FGWPE/F Wall Plug Gen5, FGSD002 Smoke Sensor
EUROtronic: SPIRIT Wall Radiator Thermostat Valve Control
Shelly2.5 Rollladenaktoren
Zipato Bulb 2, Osram und InnrLight

obi

Hallo,

ich wollte auch mal fragen wann es hierzu eine Lösung gibt?

VG Sebastian