Arduino Asksin library

[trilu]

kann ich mir irgendwo deinen code anschauen - ich glaube ich kann das was lernen

[LJ_Skinny]

Nein der Code ist nur bei mir lokal. Die Änderungen will ich dir gerne zukommen lassen.
Es gibt 2 Möglichkeiten:

1. Branch in deinem Repository. Dann könnten wir den Stack gemeinsam pflegen. Bis jetzt habe ich die Änderungen im Code mit Kommentaren versehen und einen Compiler-Switch verwendet. Mein Code sollte sich entsprechend bei dir noch kompilieren lassen.

2. Ich gebe dir meine Änderungen und du nimmst dir die Teile raus, die du gebrauchen kannst.

Langfristig werde ich die Streaming-Klassen ebenfalls entsorgen, da sie nicht so performant sind und nicht auf jedem Target gleich gut unterstützt werden. Für die reine Debug-.Ausgabe gibt es auch andere Möglichkeiten. Mein Problem ist, dass ich beim STM32 nicht mit dem Arduino Framework arbeiten kann. Deswegen nimmt mein Kompiler mal mehr oder weniger gute Standard-Bibliotheken.

Hast du die Klassen bisher allein geschrieben? Für die AVR ist der Code mit Arduino gut augestellt. Wenn man mehrere Plattformen unterstützen will, so wie ich, dann wird man um einige Änderungen nicht drumherum kommen. Weil Plattformunabhängig bedeutet, dem AVR wird etwas mehr an Ressourcen abverlangt und der Code wird nicht mehr ganz so optimiert sein.  Wenn ja kann man beide Projekte als eins laufen lassen. Anders werden die beiden Projekte irgendwann zuweit auseinander sein, damit Bugfixes/Features einfach ausgetauscht werden können.


Viele Grüße

Holger

[trilu]

puh, immer diese entscheidungen 
eigentlich habe ich viel zu wenig ahnung vom programmieren. wenn die hal zusätzlich resourcen kostet ist das schlecht,
da nicht wirklich viel platz im 328 übrig ist. auf der anderen seite hat das arduino zeug ja auch schon eine hal eingebaut.
am liebsten würde ich zusammen entwickeln - mir fehlt für viele sachen einfach die zeit und das technische wissen.
naja, und ideen hätte ich auch sooooo viele 

lass uns doch so machen - du schickst mir mal deinen code und dann entscheiden wir...

zur debug ausgabe schreibst du, dass es da auch andere möglichkeiten gibt, was wäre das?

viele grüße
horst

[kuek]

Hallo Peter,

falls Du noch interesse hast. Der sketch ist im Anhang. Nutzt jedoch eine alte relay.h und .cpp die ins den lib ordner muss.

Grüße, kuek

Hallo Zusammen

Unterstützt die Library max. 1 Homematic-Gerät oder konnten auch schon mehrere Geräte emuliert/nachgebildet werden ?
Der 1-fach Aktor HM_LC_SW1_BA_PCB ist als Beispiel enthalten, hat schon jemand den 4fach Aktor HM_LC_SW2_BA_PCB probiert ?

Gruss Peter

[PeterS]

Hallo kuek
Werde es die Tage mal testen und feedback geben
Gruss Peter

[vbs]

Danke für die Lib erstmal! Echt super!

Ich habe leider ein Problem und ich komme da einfach nicht weiter:
Und zwar hab ich einen Selbstbau-Sensor von Dirk und das Problem ist, dass im Schnitt nur ca. 50% der vom Sensor gesendeten Nachrichten beim FHEM ankommen. Ich benutze einen HMLAN. Die fehlgeschlagenen Nachrichten sind einfach komplett nicht zu sehen im HMLAN.

Nun hab ich schon ziemlich viel mit der Firmware des Sensors rumgespielt und folgendes rausgefunden:
Das Problem verschwindet (also es kommen ca. 100% der Nachrichten an), wenn ich die Nachrichten mit "Burst" sende. Also wenn ich CC110x::sendData mit einer "1" als zweiten Parameter aufrufe. Das ist natürlich erstmal nur ein Workaround und ich hätte auch gerne ohne Burst eine stabile Kommunikation.

Ich hab schon die Doku des CC1101 studiert (leider verstehe ich nur grob die Hälfte wegen mangelnder Kenntnisse) und wenn ich das richtig verstehe, dann bewirkt das Senden mit Burst, dass die Lib den CC1101 vor dem Senden schon für 360ms in den TX-Modus schaltet. Wenn der CC1101 in den TX-Modus geschaltet wird ohne Daten im TX-FIFO, dann sendet er wohl einfach die Präambel (101010101...) bis Daten in den TX-FIFO gesteckt werden.
Also das heißt einfach, dass der Burst Modus eine extrem lange (360ms) Präambel zur Folge hat (anstatt nur der sonst üblichen 4 Bits)?

Also kurz gesagt, bekomme ich nur eine stabile Kommunikation hin, wenn ich vor der eigentlichen Nachricht für 360ms (100ms reichen auch, hab ich getestet) Präambeln sende.
Nun kann ich eigentlich nur raten, voran das liegen könnte:
Es sieht für mich so aus, als würde mein HMLAN schlafen und auch nur ab und zu aufwachen, um Daten zu empfangen (burst-like). Oder aus anderen Gründen bekommt der HMLAN nicht mit, dass da gerade eine Nachricht vorbei gekommen ist.

Hat da jemand evtl. irgendwelche Ideen zu? Ich komme da einfach im Moment nicht weiter Bin für jegliche Tipps dankbar.

[unimatrix]

ist die Lib nicht mehr im Git ? oder umgezogen?

habe nur diese URL:

https://github.com/trilu2000/AskSinLib

[trilu]

doch, doch - ist hier
https://github.com/trilu2000/AskSin

aber nach dem merge mit dirks änderungen gehen die meissten beispiele nicht und ich bin noch nicht dazu gekommen das wieder gerade zu ziehen.

[unimatrix]

danke. wollte nur mit der neuesten Lib mal rumspielen.

[unimatrix]

Habe nun eine Frage zur Lib:

in der Methode HM::sendOut() wird überprüft, ob der Empfänger der Nachricht identisch mit dem Device selbst ist (als HMID = Empfänger). Dann werden die Daten in den Receive-Buffer kopiert.

Code Auswählen Erweitern


if (memcmp(&send.data[7], HMID, 3) == 0) { // if the message is addressed to us,
            memcpy(recv.data,send.data,send.data[0]+1); // then copy in receive buffer. could be the case while sending from serial console
        }


Es wird aber offenbar trotzdem auch gesendet - oder zumindest versucht. Soweit ich das nachvollziehen konnte kommt es hier meistens zu Problemen, da kein ACK (von sich selbst) empfangen wird. Mir ist nicht ganz klar, wie das läuft. Ich hätte angenommen, der Tranceiver kann natürlich nicht gleichzeitig Senden und sich selbst empfangen.

Kurz: Gibt es einen vernünftigen Grund hier überhaupt zu senden bzw. es zu versuchen? Dies scheint mir die Ursache für Verzögerungen zu sein die ich bei dem 1-fach-Schaltaktor (mit der Custom-FW) habe. Bei dem kommt es ja aufgrund der kombinierten Remote-Aktor Funktionilität ständig dazu, dass man an sich selbst "senden" will.

[trilu]

mhh, ich weiss nicht aus welcher funktion dein code schnippsel stammt, aber grundsätzlich sende ich nicht an mich selbst...

Code Auswählen Erweitern

void     HM::send_out(void) {
if (bitRead(send.data[2],5)) send.retries = dParm.maxRetr; // check for ACK request and set max retries counter
else send.retries = 1; // otherwise send only one time

send.burst = bitRead(send.data[2],4); // burst necessary?

if (memcmp(&send.data[7], dParm.HMID, 3) == 0) { // if the message is addressed to us,
memcpy(recv.data,send.data,send.data[0]+1); // then copy in receive buffer. could be the case while sending from serial console
send.counter = 0; // no need to fire
} else { // it's not for us, so encode and put in send queue

send.counter = 1; // and fire
send.timer = 0;
}
}
weil wenn an sich selbst adressiert, dann send counter auf 0 - heisst nicht senden....

[unimatrix]

Hallo Trilu,

wie ich inzwischen bemerkt habe, wurde das gepostete Codeschnippsel wohl von jab für den UP-Aktor selbst geändert. Insofern sorry für die Frage.

Ich habe mich in den letzten Tagen sehr intensiv mit der Lib und der Anwendung von JAB beschäftigt. Da ich bisher weder Panstamps noch Arduinos habe sondern tatsächlich als Experimentierhardware nur den HM_LC_Sw1PBU_FM habe ich halt überwiegend mit dem dort vorhandenen (und offenbar verändertem) Code gearbeitet. Die Struktur der aktuellen Lib im Git und die der dort eingebundenen ist grundverschieden. Da muss ich noch hinterkommen. Ich staune aber inzwischen über mich selbst und ich denke ich habe die Lib überwiegend verstanden. Dazu zählte auch, diesen Thread hier (und andere) mehrere male zu lesen ...

In diesem Thread wird immer wieder über 2 Dinge gesprochen:

- ein Perl-Script um die register.h zu erzeugen für selbst "ausgedachte" Geräte
- ein Anwendungsbeispiel als Dimmer.

Gibt es das wirklich oder waren das nur Ideen?

Ich habe  mir inzwischen Panstamps bestellt, das wird aber noch dauern (Shop ist im "Urlaub") und ich will ja JETZT was machen ... eines meiner Ziele ist es eine Custom-FW auch für den HM-LC-Dim1TPBU-FM zu schreiben (also die Dimmer-Variante des UP-Schaltaktors, zu dem es schon die Custom-FW gibt.  Die ist hardwaremäßig praktisch identisch, nur dass eben kein Relass sondern ein Mosfet zum Dimmen dran hängt.

Hab ursprünglich überlegt, für Dimmversuche die eingebaute LED zu nehmen, aber die hängt dummerweise an einem nicht-PWM Port.

Hautparbeit dürfte wohl das Implementieren des Dimmer-Registersets mit den entsprechenden Logiken/Aktionen sein (Die Sets sind ja bei Dimmern deutlich größer, es müssen Rampen mit unterschiedlichen Zeiten usw. unterstützt werden.

Daher meine Frage ob es hier schon irgendetwas zu gibt, was ich als Denkansatz nehmen könnte.

Nochmals vielen Dank!

[trilu]

Freut mich das dir die lib gefällt und du dich damit beschäftigen willst. Das Perl Script gibt es schon. Liegt auf dem git und heisst destillregs.pm.
Damit kannst du dir den Inhalt für die register.h generieren lassen.
Ein Dimmer Modul habe ich noch nicht gemacht, ist aber sehr ähnlich dem Schaltmodul. Statt schalten müssen die Dimm-Register noch ein gebaut werden.

Ich bin gerade dran die Lib zu optimieren und zu dokumentieren. Ich habe nur sehr wenig Zeit, deshalb wird esnoch eine Weile dauern bis was vorzeigbares raus kommt.
Viele Grüsse
Trilu

[jab]

Moin unimatrix,

Ich sende Nachrichten an den Schalter selbst damit FHEM das auch mitbekommt. Generell gibt es da aber noch Probleme. Ich hab aktuell leider nicht so viel Zeit um mich drum zu kümmern. In ein paar Wochen vermutlich wieder.


Gruß
Jan

[unimatrix]

Hi Jab,

ja das hab ich inzwischen dann auch so verstanden. Ich habe diesen Teil durch senden an Broadcast ersetzt. Dann bekommt es FHEM genau so mit, und die Probleme sind weg. Ich teste das mal eine Weile, ob es noch zu Nebenwirkungen kommt.

Danke für die Hinweise wegen Perl und Dimmer. In der original-FW hat der Dimmer ja noch virtuelle Kanäle, die mit dem physikalischen verknüpft werden können. Alles ein wenig aufwändiger. Werde das erstmal mit dem Panstamp und einer LED machen bevor ich mich traue den Original-Dimmer zu zerflashen.

Das Zeitproblem ist mir klar. Ich mache das auch nur als "Ausgleich" von Arbeit und Familie...wie wohl die meisten hier. Wenn ich meiner Frau erkläre, dass ich in den Lichtschalter eine eigene Software einspiele, dann .... naja ihr kennt die Geschichte wohl...