Signalduino Entwicklung

[pejonp]

...
Vielen Dank für Deinen Support.
Leider ist das alles nicht so ganz stimmig.

Daten aus unterschiedlichen Quellen passen nicht zum CrestaProtocol.pdf

# aus RF_Receiver:
# 58753DBACAEEBEDD55953900
# 58753DBA8AEEBEDD55D50300
# 50753DBA8AEEBEDD55D503
# 58753DBACAEEBEDD55953900
# 5875E2BA8A80BFD1AD915400
# 58753DBA4AEEBEDD55151500
# 5875E2BA4A80BFD1AD514200
# 5875E2BACAD7BFD1AD861000
# 287555500500
# 58753DBA4AEFBEDD55146D00
# 50753DBA8AEFBEDD55D400
....
~josef

Hallo Josef,

ich habe 2x Bresser Art.No. 70-9993 5 Kanal. Bei diesem String "5875 BD BA 4A C2 BE C8 55 AC 0A 00"  kommen bei deinem Programm die richtigen Daten herraus. Die Checksumme (0xBD^0xBA^0x4A^0xC2^0xBE^0xC8^0x55^0xAC ) ist hier Null. 

0x75 data: data id: 0, channel: 5, temp: 24.6, humi: 58

Anzeige auf dem ThermoHygro:
Channel 5 24,6°C 58%

Versuche einmal diesen Sketch auf den Signalduino auszuspielen. In der Console vom Programm Arduino 1.6.1 sollte dann so etwas angezeigt werden.
...
Temperature: 24.5 deg, Humidity: 54% REL, Channel: 5
Temperature: 24.5 deg, Humidity: 54% REL, Channel: 5
Temperature: 23.7 deg, Humidity: 53% REL, Channel: 2
Temperature: 23.7 deg, Humidity: 53% REL, Channel: 2
...

Tschüß Jörg

[Sidey]

Hallo Josef,

Ich wünsche mir, dass 00_SIGNALduino.pm die Cresta Signale als "CRxx75xyz" oder "CR75xz" an das zu schreibende CRESTA fhem Modul 'dispatched'.

Wozu sollte ich noch CR davor schreiben?  Was würde das nutzen? Ich lass mich ja gerne mit Argumenten überzeugen.
Das mit den Buchstaben vor das Signal schreiben, das schränkt einen später nur ein. Es gibt schon eine Menge Module, welche anhand den 1. Buchstaben ermitteln, ob die Daten für sich bestimmt sind. Irgendwann gehen einem die Buchstaben aus.

Meiner Meinung nach, reicht es aus auf valide Längen zu filtern und dann noch nach 0x75.
Die Regex kann ich dir jetzt nicht sehr gut aufschreiben. Da gibt es bestimmt elegantere Methoden, aber mit folgendem Match Statement wäre schon recht sicher, dass es sich um das Cresta Protokoll handelt: (zumindest die, welche ich jetzt hier im Thread gefunden habe)
/[5][0|8]75[A-F0-9]$/

Alles was mit 5078 oder 5878 beginnt und anschließen nur valide Hex Zeichen enthält würde dann verarbeitet werden.

Da das Längenfeld im Signalduino noch falsch berechnet wird,  müssen die validen Längen noch angepasst werden.
Des weiteren kann es gut sein, dass es Sensoren gibt, welche eine andere Anzahl an Bytes überträgt. Aber das müsste man im Modul dann ja auch ermitteln, damit man die passenden Routinen aufruft um die Daten zu Dekodieren.

Hab noch mal nachgesehen. Die Längenberechnung stimmt.
Es wird in Bit umgerechnet z.B. 0x58 = 88 Bits.

Grüße Sidey

[hjgode]

Hallo Sidey

OK, jetzt verstehe ich, warum Du kein CR oder so davor schreiben willst. Aber ich hatte schon mal Ärger mit 'gleichen' Matchstrings in verschiedenen Modulen, daher dachte ich CR als Kennung wäre 'sicherer'.

Ich gehe jetzt mal von  /^[5][0|8]75[A-F0-9]+$/ aus.

Als Referenz habe ich noch mal ein paar Testdaten aus einem modifizierten RemoteSensor Sketch angehängt. Diese haben noch kein Längen-Byte vorne weg. Ausserdem soll mein Perl DecodeThermoHygro auch die Daten von Jörg verarbeiten.

Gruss und Danke

Josef

[Sidey]

Hi,

was haltet ihr davon, wenn wir die Entwicklung des Cresta Modules in Github verlagern.
Ich kann dort einen Entwicklungszweig erstellen und euch auch zum ändern berechtigen.
Ihr müsstet euch nur bei Github anmelden.

Den Code zum Cresta Decoder würde ich dann aus den Beiträgen zusammen suchen und mit dem Cresta Modul kombinieren.

Vermutlich läuft er nicht gleich, aber in Github kann man dann gezielt auch erkennen, welche Zeile wie verändert wurde und weshalb.

Grüße Sidey

[Kuzl]

Hallo Sidey,

meiner Meinung wär das ganze Signalduino zeug besser im contrib Zweig von fhem im SVN aufgehoben.

Gruß,
Kuzl

[Sidey]

Hi Kuzl,

da möchte ich es erst einchecken, wenn ich wieder eine stabile Version habe.
Die agile Entwicklung möchte ich dort erst mal nichts machen, da es im FHEM svn nur einen Zweig gibt.
Ich checke halt möglichst oft ein, der Code funktioniert aber nicht unbedingt nach jedem commit.

Idee wäre, was bei RFFHEM im Master ist, kommt ins FHEM svn. Könnte man vielleicht sogar automatisch realisieren.
Den jetzt aktuellen Stand im Master verfolge ich aber nicht weiter, deshalb gibt es den nicht im svn.

Grüße Sidey

[hjgode]

Hallo Sidey

ein github zwei wäre für mich OK.

~josef

[Sidey]

Hast Du schon einen account?

[hjgode]

Jo, ich habe einen Github Account unter dem Namen "hjgode"

[pejonp]

....
was haltet ihr davon, wenn wir die Entwicklung des Cresta Modules in Github verlagern.
...

Hallo Sidey,

können wir machen. Ich habe aber so garkeine Erfahrungen mit github. Ich habe mich da mal angemeldet. Name: pejonp.
Und wie weiter ??

Jörg

[Sidey]

Hi,

Den Zweig habe ich erstellt:
https://github.com/RFD-FHEM/RFFHEM/tree/dev-cresta

Auf das Repo habe ich euch eingeladen.

Benutzern kann man es entweder mit dem Client oder man ändert den Code über den Browser.
Das überlasse ich euch, wie ihr damit arbeiten wollt.

Zu jeder Änderung die ihr macht, könnt ihr eine Beschreibung hinterlassen, was ihr geändert habt.
Andere können das sehen und auch einzelne Zeilen der Änderung kommentieren.

Grüße Sidey

[hjgode]

Hallo Sidey

vielen Dank für die Einladung. Habe auch gleich den Code von 14_Cresta.pm soweit korrigiert dass man das Modul auch laden kann ("reload 14_Cresta.pm").

Nun möchte ich auch Debuggen können. Das geht soweit in Eclipse mit einer fhem installation. Nun muß (möchte) ich das Cresta Modul manuell triggern (so, wie Du das unter http://forum.fhem.de/index.php?topic=39270.0 erfragt hast). Leider finde ich die korrekte Syntax für das Dispatch Kommando nicht. Warst Du da erfolgreich?

Beispiel aus dem Log:
2015.09.04 14:43:21 5: Cmd: >{ Dispatch($defs{cresta}, "5875BDBA4AC2BEC855AC0A00", undef) }<
2015.09.04 14:43:23 5: cresta dispatch 5875BDBA4AC2BEC855AC0A00
2015.09.04 14:43:23 5: Triggering cresta (1 changes)
2015.09.04 14:43:23 5: Notify loop for cresta UNKNOWNCODE 5875BDBA4AC2BEC855AC0A00
2015.09.04 14:43:23 3: cresta: Unknown code 5875BDBA4AC2BEC855AC0A00, help me!

Wenn das dann geht würde ich die CRC und Decode Routinen in Cresta einbauen.

Wie steht Ihr eigentlich zu externen Perl Code-Modulen? Also z.B. eine externes Modul (zB cresta_helper.pm) zu 14_Cresta.pm welches die CRC und Decode Funktionen enthält.

Danke

Josef

[Sidey]

Hallo Josef,

Du musst den Dispatch über das SignalDuino Device Laufen lassen.

Also wenn Du dein IO Device sduino genannt hast musst Du $defs{sduino} verwenden.
Der Rest von deinem Aufruf sieht gut aus.


Zum externen Perl Modul: Was würde uns das bringen?

Zu Ellipse: Gibt es da eine Doku zu, wie man Fhem in Eclipse laufen lässt? Das interessiert mich auch brennend. Ich entwickele gerade auf einem raspberry pi.

Grüße Sidey

[hjgode]

Hallo Sidey

das mit dem Dispatch funktioniert aber so nicht { Dispatch(defs(sduino), "5875...daten"...

OK, auf meinem Windows System habe ich Eclipse plus EPIC und darin fhem am Laufen. Leider geht da mein Test nano nicht (hat nen Fake FT232L). Anleitung nach der ich vorgegangen bin sende ich später.

So, hier auf meinem Linux System komme ich soweit:
(fhem.log):

Code Auswählen Erweitern

2015.09.04 17:39:26 4: SIGNALduino/msg READ: ^BMC;LL=-1054;LH=911;SL=-557;SH=414;D=5711CBA53023F5888A7F3600;C=441;^C
2015.09.04 17:39:26 5: sduino: Cresta protocol converted to hex: (5875E2BACA20BF23517F1B00) with length (96) bits

2015.09.04 17:39:26 5: converted Data to (5875E2BACA20BF23517F1B00)
2015.09.04 17:39:26 5: sduino dispatch 5875E2BACA20BF23517F1B00
2015.09.04 17:39:26 4: sduino incomming 5875E2BACA20BF23517F1B00
2015.09.04 17:39:26 4: sduino converted to bits: 0111010111100010101110101100101000100000101111110010001101010001011111110001101100000000
2015.09.04 17:39:26 4: sduino decoded Cresta protocol   , sensor id=, channel=4, temp=-42.5

2015.09.04 17:39:26 1: Cresta: UNDEFINED sensor  detected, code
2015.09.04 17:39:26 5: Triggering global (1 changes)
2015.09.04 17:39:26 5: Notify loop for global UNDEFINED _ Cresta
2015.09.04 17:39:26 2: autocreate: define _ Cresta
2015.09.04 17:39:26 1: define _ _ Cresta : wrong syntax: define <name> Cresta <code> <minsecs> <equalmsg>2
2015.09.04 17:39:26 1: ERROR: wrong syntax: define <name> Cresta <code> <minsecs> <equalmsg>2
2015.09.04 17:39:26 5: SIGNALduino/RAW READ: ^BMC;/LL=-1054;LH=911;SL=-557;SH=414;D=57
2015.09.04 17:39:26 5: SIGNALduino/RAW READ: ^BMC;LL=-1054;LH=911;SL=-557;SH=414;D=57/11CBA53023F5888A7F3600;C


Mir ist nicht klar was zum einen Channel und Temp im SignalDuino zu suchen haben und zum anderen, was code, minsecs equalmsg für Argumente für das Cresta device zu sagen haben.

~Josef

[hjgode]

Wegen Entwicklungsumgebung für FHEM: http://forum.fhem.de/index.php?topic=12050.0
Post von Fossie