Probleme mit Panstamp und xml

[Tobias]

Hi,
ich habe mir ein tolles Produkt XML gebaut zu meiner Firmware meines neuen Umweltsensors. Das Environment.xml wird sauber über die device.xml auch eingelesen wenn eine Funkmessage kommt.
Problem habe ich beim Register senden. Ich habe das erste Register 0B als ConfigRegister definiert. Dort habe ich 5 Bytes definiert.
Wenn ich nun aber senden will kommt in FHEM folgender Fehler:

Code Auswählen Erweitern

set <panstamp> regSet 0B 012F0E0105
value has to be 3.1 byte(s) in size

012F -> mein SyncIntervall (das ist nicht das TX-Intervall !!)
0E -> 00000111 -> Analog 1-3
01 -> 00000001 -> nur Temp des DS18B20
05 -> 00000101 -> Nur BatteryVoltage und DebugLED

Im Anhang die XMLs. Sieht einer meinen Denkfehler??

[justme1968]

hallo tobias,

die berechnung der register gesamt größe aus den einzelnen endpoint größen ist für endpoints die nicht ganze byte sind nicht korrekt.
es gibt auch keine möglichkeit das für alle fälle automatisch zu machen.

ich habe jetzt mal zwei dinge eingebaut:
- es wird versucht die größe aus der höchsten position abzuleiten.
  das ist noch unvollständig und auch nicht 100% möglich, sollte aber gehen so lange es immer byte sind.

- es gibt jetzt die möglichkeit im xml die größe zusätzlich auch beim ganzen register anzugeben.

bite probiere mal die angehängte verision. erst mit unverändertem xml und dann setz bitte für das register 0b im xml die size auf 5.

gruss
  andre

[Tobias]

bin kurz weg, dann mach ichs... aber wie und mit welcher Syntax wird die Gesamtgröße gesetzt? Hab ich etwas überlesen?
War das XML aus deiner Sicht sonst io?

[justme1968]

mit einem zusätzlichen

Code Auswählen Erweitern

<size>5</size> auf register ebene statt auf endpoint ebene.

sonst schaut es auf den ersten blick ok aus.

ps: ich würde nicht alles in ein register packen sondern es trennen. das macht später erweiterungen einfacher. bei einem register das eigentlich auch nur ein mal beschrieben wird kommt es nicht so sehr auf den verminderten funk verkehr an.

[Tobias]

eingebaut, auch ohne <size> angabe hat er jetzt die Config gesendet

Nächstes Problem, der Panstamp sendet die Config im Register 0B wie folgt:

Code Auswählen Erweitern

SWAP_F1 -> broadcast (0,0-07): status SWAP_F1 0B:012F010102
mit obigem XML kommt aber:

Code Auswählen Erweitern

0B.0-Sync_Interval
012F
0B.1-HAS_Analog1_(1=Enable_0=Disable)
1
0B.10-Transmit_SolarVoltage_(1=Enable_0=Disable)
0
0B.11-LED_Debugging_(1=Enable_0=Disable)
0
0B.2-HAS_Analog2_(1=Enable_0=Disable)
0
0B.3-HAS_Analog3_(1=Enable_0=Disable)
0
0B.4-HAS_Analog4_(1=Enable_0=Disable)
0
0B.5-HAS_DS18B20_(1=Enable_0=Disable)
1
0B.6-HAS_DHT22_(1=Enable_0=Disable)
1
0B.7-HAS_TSL2560_(1=Enable_0=Disable)
1
0B.8-HAS_BMP180_(1=Enable_0=Disable)
1
0B.9-Transmit_BatteryVoltage_(1=Enable_0=Disable)
1
wie man sieht, steht 0B.5 - 0B.8 komplett auf 1, also alle 4 = 1, dürfte aber nur einer =1, die anderen müssten auf 0 stehen.
Verstehst du das? Noch ein Fehler bei Bit-Endpoints?

EDIT: habe im Sketch mal hart eine 0x00 mitgesendet, also 0B:012F010001, aber in den Readings stehen diese 4 immer(!) auf 1. Ich bin jetzt ratlos...

[justme1968]

stell mal bitte verbose auf 5 und schau im log was wirklich gesendet und als anzwort empfangen wird.

eigentlich wird beim senden eines kompletten register nichts mehr auf bit ebene gemacht und beim lesen wird nur abgearbeitet was tatsächlich rein kommt.

aber möglich ist alles. endpoints < ein byte sind bis jetzt nur mit dem binout sketch getestet und da gibt es keine lücken. 

[Tobias]

hatte eben noch ein EDIT oben geschrieben...
Dazu jetzt das Log...

Code Auswählen Erweitern

2015.01.13 14:36:09 5: panStamp/RAW: /(D72F)00F1000100F100000000220
2015.01.13 14:36:09 5: panStamp/RAW: (D72F)00F1000100F100000000220/000000E
/015.01.13 14:36:09 5: panStamp/RAW: (D72F)00F1000100F100000000220000000E
(D72F)0
2015.01.13 14:36:09 5: MyPanstamp: 00F1000100F100000000220000000E -94.5 47
2015.01.13 14:36:09 5: MyPanstamp dispatch 00F1000100F100000000220000000E
2015.01.13 14:36:09 4: SWAP_F1 -> broadcast (0,0-01): status SWAP_F1 00:000000220000000E
2015.01.13 14:36:09 5: MyPanstamp sending 000001F101
2015.01.13 14:36:09 5: SW: F101000001F101
2015.01.13 14:36:09 5: MyPanstamp sending 000001F102
2015.01.13 14:36:09 5: panStamp/RAW: (D72F)0/0F1000200F10303

2015.01.13 14:36:09 5: MyPanstamp: 00F1000200F10303 -94.5 47
2015.01.13 14:36:09 5: MyPanstamp dispatch 00F1000200F10303
2015.01.13 14:36:09 4: SWAP_F1 -> broadcast (0,0-02): status SWAP_F1 03:03
2015.01.13 14:36:09 5: panStamp/RAW: /(D62B)00F100030
2015.01.13 14:36:09 5: panStamp/RAW: (D62B)00F100030/0F101000
2015.01.13 14:36:09 5: panStamp/RAW: (D62B)00F1000300F101000/00002

2015.01.13 14:36:09 5: MyPanstamp: 00F1000300F10100000002 -95 43
2015.01.13 14:36:09 5: MyPanstamp dispatch 00F1000300F10100000002
2015.01.13 14:36:09 4: SWAP_F1 -> broadcast (0,0-03): status SWAP_F1 01:00000002
2015.01.13 14:36:09 5: SW: F101000001F102
2015.01.13 14:36:09 5: panStamp/RAW: /(D72E)00F1000400F10200000001

2015.01.13 14:36:09 5: MyPanstamp: 00F1000400F10200000001 -94.5 46
2015.01.13 14:36:09 5: MyPanstamp dispatch 00F1000400F10200000001
2015.01.13 14:36:09 4: SWAP_F1 -> broadcast (0,0-04): status SWAP_F1 02:00000001
2015.01.13 14:36:13 5: panStamp/RAW: /(D530)00F1000500F10302

2015.01.13 14:36:13 5: MyPanstamp: 00F1000500F10302 -95.5 48
2015.01.13 14:36:13 5: MyPanstamp dispatch 00F1000500F10302
2015.01.13 14:36:13 4: SWAP_F1 -> broadcast (0,0-05): status SWAP_F1 03:02
2015.01.13 14:36:15 5: panStamp/RAW: /(D72F
2015.01.13 14:36:15 5: panStamp/RAW: (D72F/)00F1000
2015.01.13 14:36:15 5: panStamp/RAW: (D72F)00F1000/600F10A
2015.01.13 14:36:15 5: panStamp/RAW: (D72F)00F1000600F10A/0384
(D
2015.01.13 14:36:15 5: MyPanstamp: 00F1000600F10A0384 -94.5 47
2015.01.13 14:36:15 5: MyPanstamp dispatch 00F1000600F10A0384
2015.01.13 14:36:15 4: SWAP_F1 -> broadcast (0,0-06): status SWAP_F1 0A:0384
2015.01.13 14:36:15 5: panStamp/RAW: (D/72F)00F1000700F10B012F0
2015.01.13 14:36:15 5: panStamp/RAW: (D72F)00F1000700F10B012F0/10001

2015.01.13 14:36:15 5: MyPanstamp: 00F1000700F10B012F010001 -94.5 47
2015.01.13 14:36:15 5: MyPanstamp dispatch 00F1000700F10B012F010001
2015.01.13 14:36:15 4: SWAP_F1 -> broadcast (0,0-07): status SWAP_F1 0B:012F010001
2015.01.13 14:36:15 5: panStamp/RAW: /(D62F)00F1000800F10C00000000
(D72D)00F1000900F10302

2015.01.13 14:36:15 5: MyPanstamp: 00F1000800F10C00000000 -95 47
2015.01.13 14:36:15 5: MyPanstamp dispatch 00F1000800F10C00000000
2015.01.13 14:36:15 4: SWAP_F1 -> broadcast (0,0-08): status SWAP_F1 0C:00000000
2015.01.13 14:36:15 5: MyPanstamp: 00F1000900F10302 -94.5 45
2015.01.13 14:36:15 5: MyPanstamp dispatch 00F1000900F10302
2015.01.13 14:36:15 4: SWAP_F1 -> broadcast (0,0-09): status SWAP_F1 03:02


[justme1968]

da war tatsächlich noch mehr kaputt. die offset berechnung hat nicht funktioniert für endpoints die != 1 byte waren.

in der angehängten version sollte das jetzt gehen.

wichtig: es gibt für diese unterteilten register folgende einschränkung:
  - ein endpoint muss entweder vielfaches von einem byte gross sein oder genau ein bit.

das trifft bei dir aber überall zu.

mir ist noch etwas aufgefallen: du hast mehr als 10 endpoints in einem register. die endpoints sind leider nicht wie die register in hex sondern dezimal und werden nicht mit links auch nicht mit nullen aufgefüllt. die sortierreihenfolge in den readings ist also unschön. ich muss mal schauen ob ich das rückwärts kompatibel ändern kann.

gruss
  andre

[Tobias]

Super, passt

Es sind in dem ConfigRegister nur deshalb so viele Endpoints weil man soviel konfigurieren kann. Der Sketch soll nur einmal kompliliert werden und dieser soll dann überall identisch laufen. Sowohl auf meinem Panstam-Bodenfeuchtesensor als auch auf dem neuen Umweltsensor - Ohne immer neu zu kompilieren.