Arduino Asksin library

[trilu]

Keine Ahnung was ich gedrückt habe, aber jetzt kommen auch längere Strings :-)
Available commands:
  <nnn> i    - set device ID (3 bytes)
  l          - load configuration from EEPROM
  w          - write configuration to EEPROM
-> DA A2 40 1F A6 5C 63 19 63 01 A5 (11)
-> DA A0 03 1F A6 5C 63 19 63 BF 24 3A 37 3E 14 05 EB B4 68 47 C1 38 C7 84 62 (25)
-> DA 80 02 63 19 63 1F A6 5C 01 01 C8 00 (13)
-> DB A0 02 63 19 63 1F A6 5C 04 95 03 A5 EB 8A B7 02 (17)
-> DB 80 02 63 19 63 1F A6 5C 00 81 DD DE 9F (14)
-> DC A2 40 1F A6 5C 63 19 63 01 A7 (11)
-> DC A0 03 1F A6 5C 63 19 63 72 28 0C DE A2 9D 67 3B 10 0A B7 3C C0 64 8F 9C (25)
-> DC 80 02 63 19 63 1F A6 5C 01 01 C8 00 (13)
-> DD A0 02 63 19 63 1F A6 5C 04 9C 0A AC E2 83 BE 02 (17)
-> DD 80 02 63 19 63 1F A6 5C 00 89 94 68 A0 (14)
-> DE A2 40 1F A6 5C 63 19 63 01 A9 (11)
-> DE A0 03 1F A6 5C 63 19 63 5E 93 DC 7B 9F 2D 46 D3 3D 55 6E E4 CF 25 85 65 (25)
-> DE 80 02 63 19 63 1F A6 5C 01 01 C8 00 (13)
-> DF A0 02 63 19 63 1F A6 5C 04 84 12 B4 FA 9B A6 02 (17)
-> DF 80 02 63 19 63 1F A6 5C 00 01 49 C7 D4 (14)
-> E0 A2 40 1F A6 5C 63 19 63 01 AB (11)
-> E0 A0 03 1F A6 5C 63 19 63 31 FE B8 7F 10 3A FE C6 9C 8E 5D 3B 1F 0B 46 AC (25)
-> E0 80 02 63 19 63 1F A6 5C 01 01 C8 00 (13)
-> E1 A0 02 63 19 63 1F A6 5C 04 8C 1A BC F2 93 AE 02 (17)
-> E1 80 02 63 19 63 1F A6 5C 00 A9 99 4F 33 (14)
-> E2 A2 40 1F A6 5C 63 19 63 01 AD (11)
-> E2 A0 03 1F A6 5C 63 19 63 85 A6 31 E2 C8 88 80 4C DA 4C 0E F7 94 C5 A4 BB (25)
-> E2 80 02 63 19 63 1F A6 5C 01 01 C8 00 (13)
-> E3 A0 02 63 19 63 1F A6 5C 04 85 13 B5 FB 9A A7 02 (17)
-> E3 80 02 63 19 63 1F A6 5C 00 C0 A3 45 46 (14)

[trilu]

Ich versuche gerade den Empfang auf Interrupt basiert umzubiegen und komm in den Wald.
Vielleicht hat ja jemand Lust und Zeit sich auch einmal daran zu versuchen.

[martinp876]

mir ist jetzt der Aufbau nicht klar (muss evtl noch einmal den Thread lesen?)
1FA65C sendet einen trigger an 631963 sowie einen AES reply hinterher.
631963  schaltet "ein" und sendet einen AES request. Dann auch noch eine Quittung an sich selbst - mit einem etwas seltsamen Status.

Wird der Code aus Panstamp erzeugt? Mit welcher SW? Wo hast du gedrückt?

Gruss Martin

[trilu]

nein, musst du nicht lesen :-)
ich habe heute noch ein paar verbesserungen an der empfangsroutine gemacht, war noch buggy - jetzt läuft sie stabil und ich bekomme alle messages mit. jetzt würde ich gerne mit dem pairing anfangen.

ich habe jetzt mal testweise die pairing taste von einem 6 tasten wandsender aufgezeichnet, der string sieht so aus:
-> 2C A2 00 1F A6 5C 63 19 63 11 00 A9 4B 45 51 30 33 31 38 38 31 30 40 06 00 A2 (26)

jetzt bräuchte ich deine hilfe bei der interpretation. was ich verstanden habe ist
2C - Messagecounter
A2 - ??
00 - Message type, 00 heisst pairing?
1F A6 5C - eigene DeviceID
63 19 63 - zu pairende DeviceID, wäre nach einem Reset leer?
11 00 A9 4B 45 51 30 33 31 38 38 31 30 40 06 - keine ahnung
00 - channel?
A2 - weiss nicht?

kannst du hier ein wenig licht ins dunkel bringen?
muss ich den AES Key speichern?

[martinp876]

2C - Messagecounter
A2 - Bitfeld - flags für die Message. Hier: message an die Zentrale (2), ACK angefordert (20) und message (80)
00 - Message type, 00 heisst pairing? - kann man so sagen
1FA65C - sourceID
631963 - destination ID. 000000 ist broadcast. Bei dieser message kann es immer 000000 sein,
11   FW version
00A9 Model identify
4B 45 51 30 33 31 38 38 31 30 Seriennummer Ascii kodiert: KEQ0318810
40 Klasse, Subtype identify
06 Anzahl Kanäle (ist aber nicht immer so!!!)
00A2 unklar - sagt wahrscheinlich etwas über Kommunikations-modi aus.

Den Key musst du nicht speichern. Der gesendete String aendert sich immer, sonst wäre es zu einfach, es zu knacken. Der Key wird m.e. zu einem anderen Zeitpunkt ausgetauscht.


Du hast also den panstamp als IO device laufen. Kann man machen. Sortieren wir einmal:
Wenn du einen Panstamp als IO-device nutzen willst musst to keinerlei HM messages dekodieren. Du schickst sie einfach an CUL_HM. Wir müssen hierfür nur ein neues IO modul bauen, dann haben wir noch eine alternative zu HMLAN und CUL/CUNO,...

Der schritt, der mich interessiert ist,den Panstamp als Aktor oder Sensor zu nutzen. Das wird wohl der nächste Schritt. Ich werde einmal ein paar messages ausarbeiten, die der Panstamp schicken muss. Wird der so etwas wie eine Anlerntaste haben?
Gruss Martin

[trilu]

Vielen Dank!
Meine HW läuft zur Zeit als Scanner :-)
Er belauscht einfach nur die Kommunikation. Ich will auch keinen CUL nachbilden, sondern eine Plattform für eigene Devices. Egal ob Aktoren oder Reaktoren. Blödes Wort!
Natürlich soll man damit auch Sensorwerte übertragen können.

Ich möchte nur als nächstes das pairen einbauen. Sonst bekommen wir das Device ja nicht sauber ins HM Netzwerk. Deshalb ja auch die Frage nach dem letzten String. Das ist ja dann der String den meine HW senden muss, so dass ein CUL oder HMLan darauf antworten kann.

Zur Frage nach der Anlerntaste. Ja werden wir wohl brauchen. Für den Anfang und zum Entwickeln werde ich die Taste aber über die serielle Konsole machen. Das macht das Leben leichter beim Testen...

Vielleicht kannst du mir auch schon die Antwort auf den pairing String erklären?
Noch eine Frage, der Messagecounter zählt einfach nur bis 255 und startet wieder bei 0. Bezieht sich der Counter auf Tx, oder zählt er auch bei Rx hoch?

[herrmannj]

Das ist ja mal ein Plan !

Der Portabilität zuliebe plädiere ich für *eine* platform. Ob RFM12B auf HM geht weiß ich nicht (theoretisch müsste das aber gehen) - wenn ja wären die jeelinks / nodes eine passende Platform. Panstamp mit den ccxx sicher die andere Alternative wobei ich der Meinung bin das die jeelinks das größere Angebot an "shields" haben (temp, hum, druck, piri, licht, led). Da bin ich aber nicht mehr auf dem laufenden, kann mittlerweile bei den PAN Stamps ja genauso gut aussehen.

Grüße
Jörg
 

[trilu]

Mein Vorhaben basiert auf dem cc1100 Chip von TI.
Für die JeeNodes gibt ein gutes Protokoll. Die RF12 Module cc1100 kompatibel zu machen wäre ein riesen Aufwand. Die Jeelib für die Peripherie kann man auch auf der panstamp HW nutzen.

[trilu]

so, mal wieder ein update der files...
die empfangsroutine sollte jetzt stabil sein und alles anzeigen!
das handling von GDO_0 ist auf panStamp HW angepasst.

[justme1968]

kannst du noch irgendwelchen input oder logs gebrauchen ?

gruss
  andre

[martinp876]

So, hier der Beginn des interworkings. Erst einmal sind einige Parameter abzustimmen, siehe Text.

Panstamp HM protokoll

A) Message sequenznummer
  Die Sequenznummer ist ein Wert zwischen 00 und FF mit einfachem Überschlag bei FF nach 00.
  Wichtig ist, dass ACKs immer die Sequenznummer der ankommenden Message spiegeln MÜSSEN. Diese Nummer wird dann als neue genutzt und von hier weitergezählt.
  Nach reset beginnt der Zähler mit '00'

B) Anlernmessage
1) Seriennummer: Jedes HM device hat eine 10-stellige Seriennummer
  Bedeutung: für den Betrieb unwichtig.
  Kann man eine Solche Nummer aus dem Device ableiten?
  Vorgabe für den Test "PS00000001" = 50533030303030303031
  Offen: wie soll die Nummer generiert werden? Fixer Wert?
2) ModelID: ist ein 2-Byte wert. HM füllt diese von 0000 an auf, also nutzen wir hohe Werte
  Vorgabe für den Test: 8001
3) subType: werte ich nicht mehr aus. Ist eine Art Gruppen-ID
  Vorgabe für den Test: 9F
4) DevInfo: hat noch unbekante bestandteile Mit unter steht die Anzahl der Kanäle drin.
  Vorgabe für den Test: 010101
5)HMID: exterm wichtig. Wir brauchen ein verfahren, diese eindeuting zumindest im System zu setzen. Sie muss ggf geaendert werden koennen
  Vorgabe für den Test: FF00xx mit xx eine Hex zahl zwischen 00-FF

Fertige Anlernmessage:
nn A200 FF0001 000000 10 8001 50533030303030303031 010101
Ohne Leerzeichen, versteht sich.

C) Acknowledge
  wenn das Flag der empfangenen Message ein ACK anfordert muss eine Antwort kommen. Im einfachsten Fall ein ACK.
  Das Flag (erste Byte nach SeqNummer) hat ein response-request wenn "Flag & 0x20" war ist.
  Beispiel:
  Request: nn A200 FF0001 112233 10 8001 50533030303030303031 010101
  ACK:     nn 8002 112233 FF0001 00

D) Wiederhohlen
  eine Nachricht muss wiederholt werden wenn ein ACK angefordert wurde und dies nicht innerhalb von 300ms eingetrofen ist.
  Es wird 3 mal wiederholt  (default, wird einstellbar)
 

Fortsetzung folgt

Gruss Martin

[martinp876]

Part II

  A) Definition
    Parameter eines HM devices werden nicht-flüchtig in Registern gespeichert. HM gruppiert Register in Bänken mit einem Addressraum von 256 Byte. Die Bänke werden über "list" und "links" adressiert.
   Über diese Werte wird das Device-verhalten festgelegt.
   Der Speicherraum einer Registerbank wird selten komplett genutzt. Er wird nicht sequenziell genutzt sondern bestimmte Adressen haben bestimmte Bedeutung. Daher werden die auch Register genannt.
  B) Register Bänke
    List0: gibt es einmal je Device. Hier wird das pairng mit der Zenrale hinterlegt sowie Protokol-spezifische Eigenschaften
   List1: legt Parameter eines Kanals fest, welche vom Peer unabhämgig sind. z.B. Fahrzeiten eines Rollos
   List2: für Aktoren und Sensoren nicht genutzt
   List3: legt das Verhalten beim Bearbeiten eines Triggers fest. Daher gibt es List3 nur für Aktoren.  Diese Liste ist einmal je Kanal/peer kombination vorhanden. Mit jedem Peeren wird eine entsprechenden Liste angelegt.
   List4: ist das Pendant zu List3 für Sensoren, die man peeren kann.
   List5: für Aktoren und Sensoren nicht genutzt
   List6: für Aktoren und Sensoren nicht genutzt
   List7: für Aktoren und Sensoren nicht genutzt
  C) ImplementierungsDetails
    Jede RegisterBank hat einen Adressraum von 256 Byte und muss in einen Flash oder EEPROM gespeichert werden. Will man ein Device mit 6 Kanälen realisieren und jeden Kanal 8mal peeren kommen wir auf einen Speicherbedarf von :
   List0 + 6*List1 + 6*8*List3 = 55 Bänke =^ 13,75kByte
   Zu beachten ist, dass die Bänke nur zu einem geringen Teil genutzt werden. Es ist daher zu überlegen eine optimierte Speicherverwaltung vorzusehen. In C könnte man eine struktur definieren, die nur genutzte Register realisiert
  D) Lesen von Registern durch die Zentrale
    Register lesen darf nur die eingetragene Zentrale.
   Es wird IMMER eine komplette Registerbank gelesen. Einzelne Register können nicht gelesen werden.
   Message zu Lesen:
   <no>A001<src><dst><chan>04<peer><list>
   no: Message counter
   src,dst: Source und Destination HM ID. Jeweils 3 Byte in Uppercase HEX, also je 6 Byte Ascii
   chan: Nummer des Kanals, der gelesen werden soll
   peer: PeerID ist 4 Byte lang: 3 Byte HMId des peers plus 1 Byte des Peer Channels
   list: Nummer der zu lesenden Liste
   Beispiele
   nn A001 1743BF 1A0A02 00 04 00000000 00 # lesen List0: channel, peer und list ist "0"
   nn A001 1743BF 1A0A02 01 04 00000000 01 # lesen List1 den Channel 1: peer ist "0"
   nn A001 1743BF 1A0A02 05 04 00000000 01 # lesen List1 den Channel 5: peer ist "0"
   nn A001 1743BF 1A0A02 02 04 12345604 03 # lesen List3 den Channel 2: peer ist 123456, chan 04
   
   Die Antwort des Devices ist
   <no>A010<src><dst>03<addr><data><addr><data>... # max 5 byte

  E) Schreiben von Registern durch die Zentrale   
    Register schreiben darf nur die eingetragene Zentrale. Ausgenommen ist die Phase nach drücken der Anlerntaste.
   Das Schreiben von Registern ist eine Sequenz von Nachrichten.
   1: Öffnen einer Bank zum Schreiben
   2: schicken der Daten - ggf. mehrere Messages
   3: schliesen der Bank, schreiben der Daten
   Messages
   <no>A001<src><dst><chan>05<peer><list> # öffnen der Bank zum Schreiben
   <no>A001<src><dst><chan>08<addr><data><addr><data>... # max 5 byte
   <no>A001<src><dst><chan>06             # schliesen der Bank
   
   Beispiel: schreiben bein pairing:
    <no>A001<src><dst> 00050000000000
    <no>A001<src><dst> 0008 0201 0A17 0B43 0CBF # pair mit 1743bf, in Register 0A,0B und 0C der List 0
    <no>A001<src><dst> 0006

[trilu]

wow, das sieht echt gut aus was du da beschreibst :-)
kannst du mir hier noch eine auflistung geben, welche flags es noch gibt:
// A2 - Bitfeld - flags für die Message. Hier: message an die Zentrale (2), ACK angefordert (20) und message (80)

(1)
(2)  message an die Zentrale
(4)
(8)
(10)
(20) ACK angefordert
(40)
(80) message

das mit den registern wird so nicht funktionieren, der avr 328 hat leider nur 1kb :-(

[martinp876]

40 = repeater (ein repeater hat die Nachricht wiederholt). Falls beide messages empfangen wurden nur eine auswerten
10 = burst transmission. Vorläufig irrelevant, so weit sind wir nicht
8 = unbekannt
4 = config mode
1/2 = werden auch im wakeup mode verwendet. Ebenfalls zukunft

Manche sind nicht 100% sicher Sicher sind
80/40/20/10/2

Als wichtigste Fragen empfinde ich, wie du devices Einstellen willst.
- wie kann man devices eine HMID geben?
- was soll in die Seriennummer?
=> sind die lästigen Fragen, aber es ist das Fundament.

pairen ist übrigens erst einmal nicht wichtig, da wir nicht so weit sind. Das pairen können wir aber als blueprint für Register schreiben und lesen nehmen.
- wieviel Speicher steht in einem panstamp für Register zu Verfügung?

Übrigens ist ein Fehler in der ersten Beschreibung: wenn man an Broadcast sendet kann man (logisch) nie ein ACK anfordern!

Gruss Martin

[mmatt]

Sehr interesannt was hier abgeht.

Wird das Ganze dann auch auf den neuen Panstamps (CC430F5137 SOC / Texas Instruments)
funktionieren ?

Nicht, dass Ihr was tolles konstruiert, das dann "nur" mit den alten Panstamps funktioniert.
Nur so ein Gedanke ;-)

Gruss Martin