AskSin++ Library

[jp112sdl]

Wer sich für die derzeit möglichen Nachbauten/Eigenbauten interessiert, möge mal nen Blick in das AskSin++ Collection Github werfen. Dort hat Jerome jede Menge Infos zusammengetragen.

Christoph (hier leider nicht vertreten) hat sich die Mühe gemacht und die Übersicht user-friendly gestaltet.
Der Link ist nun etwas anders: https://jp112sdl.github.io/AskSinPPCollection

[Klaus0815]

Ich kopiere es mal hier rein, weiss nicht ob alle von hier den anderen Thread lesen

Es gibt Probleme mit diversen CC1101-Modulen, die wohl auf der falschen Frequenz senden (leichter Offset)

https://forum.fhem.de/index.php/topic,91740.0.html

Bestünde evtl. bei der AskSIn++-Library die Möglichkeit, die Sendefrequenz zu verändern? Müsste evtl. ein zusätzliches Register gesetzt werden oder irgendwas wird falsch initialisiert?

[fhemfreund]

Habe mir gerade das Perl script noch mal zu Gemüt geführt, da fehlt tatsächlich das Define des updateIntervall Registers, hat noch keiner gemerkt, bei mir auf RaspberryMatic ging das Einstellen immer einwandfrei 

Glaube den Fehler gefixt zu haben, habe gerade commited. Bitte neustes Perl script testen ob es damit geht - ich glaube FHEM braucht einen Restart oder reicht ein reload für das geänderte .pm file?

habe jetzt mal den neusten Stand (.pm + FW) vom Git gezogen und konnte jetzt das Sendeintervall in Fhem einstellen und soweit funktioniert auch alles sehr gut - nochmals: Top Leistung
Was mir bei meinen Tests aufgefallen ist:

1) kann den LED Mode via

Code Auswählen Erweitern


set <devicename> regSet ledMode <on|off>


leider nicht ändern. Bekomme folgende Meldung in Fhem:

Code Auswählen Erweitern


cannot calculate value. Please issue set HM_A5A501 getConfig first - invalid: not supported by FW version


2) das Lesen der Register-Werte via getConfig geht bei mir nur sehr sporadisch. Keine Ahnung woran das liegt. Das Setzen funktioniert aber einwandfrei.


Habe auch mal genauere Verbrauchsmessungen (via Fluke 8808a + Digi Oszi) gemacht, um die Batterielebensdauer abzuschätzen. Verwendet habe ich die Platine aus

Code Auswählen Erweitern


https://forum.fhem.de/index.php/topic,73954.msg656384.html#msg656384


Folgende Werte sind dabei herausgekommen:

Code Auswählen Erweitern


Standbystrom       ~20uA
Strom beim Senden  ~7mA für ca. 70ms


Das sollten theoretisch ca. ~421 Tage Lebensdauer bei einer CR2032 (230mAh) mit 20 Übertragungen pro Std ergeben. Keine Ahnung wie das Spannungsverhältnis einer CR2032 gegen Ende der entnommenen Kapazität aussieht und somit der Sensor überhaupt noch senden kann - würde vermuten, dass das weniger Tage in der Realität sind. Falls jemand auch Werte gemessen hat, wäre nett mal quer zu checken ob die im ähnlichen Bereich liegen.

Andreas

[Tom Major]

Hallo Andreas,

freut mich das der Fix mit dem Sendeintervall gleich funktioniert hat.

LED abschalten ist momentan im UniSensor1 (noch) nicht implementiert, hatte ich vor und steht auf auf der Liste, hat es aber noch nicht in die oberen Prios geschafft 

Lesen der Werte nur sporadisch, da kann ich nicht viel sagen, du drückst schon den Taster wenn du Werte lesen willst? (BIDI, BCAST Problematik, im Sketch kommentiert)

20uA Sleep ist zu viel, das geht besser, siehe
https://github.com/TomMajor/AskSinPP_Examples/tree/master/Info/SleepTest
Eventuell BOD aktiv?

Und 7mA beim Senden kommen mir etwas wenig vor, im Datenblatt stehen 16-35 mA je nach output power.

Grüße Tom

[fhemfreund]

Hallo Tom,

wg. LED: ah ok. Dann warte ich mal - das eilt für mich net.
wg. Lesen der Werte nur sporadisch: ja drücke brav den Config Taster - hab' schon ne Delle in der Fingerkuppe
Werde noch mehrere Unisensoren aufbauen; mal schauen ob das da auch auftritt.

habe gerade auch nochmal mit meinem STK600 die Fuses gecheckt:

Code Auswählen Erweitern


BODLEVEL = DISABLED
RSTDISBL = [ ]
DWEN =     [ ]
SPIEN =    [X]
WDTON =    [ ]
EESAVE =   [ ]
BOOTSZ =   2048W_3800
BOOTRST =  [ ]
CKDIV8 =   [ ]
CKOUT =    [ ]
SUT_CKSEL = INTRCOSC_8MHZ_6CK_14CK_65MS

EXTENDED = 0xFF (valid)
HIGH = 0xD9 (valid)
LOW = 0xE2 (valid)


Also keine BOD aktiv.

Habe meine Messung mit 3V Versorgung + BME280 + MAX44009 Breakout gemacht. Der Standby kam mir ehrlich gesagt auch zu hoch vor (komme in anderen ATMega Projekten teilweise in den nA Bereich beim Sleep). Habe zur Zeit noch den int. RC gefused - da auf dem Board ja ein Uhrenquartz ist: funktioniert dein Sketch auch damit (wg. Timing etc.)? Normalerweise spart das auch noch ...

Wg. Sendestrom: ok - kann nochmal mit Fast Rate sampeln (hatte das mit Medium gemacht) und nochmal den Max-Wert Speicher verwenden. Das scheint in der Tat nach Datenblatt zu wenig.
Das Fluke misst an sich sehr gut (hat einen Messverstärker). Werde mal weiter schauen ...

Andreas

[papa]

LED abschalten ist momentan im UniSensor1 (noch) nicht implementiert, hatte ich vor und steht auf auf der Liste, hat es aber noch nicht in die oberen Prios geschafft 

Das könnten wir auch direkt in die Lib einbauen. Das Register ist auf jeden Fall schon definiert. Soll bei Off die Led gar nichts mehr machen oder nur die Signalisierung beim Senden/Empfangen abgeschalten werden ?

[papa]

wg. Lesen der Werte nur sporadisch: ja drücke brav den Config Taster - hab' schon ne Delle in der Fingerkuppe
Werde noch mehrere Unisensoren aufbauen; mal schauen ob das da auch auftritt.

Könntest Du bitte mal die seriellen Ausgaben loggen, wenn es auftritt. Vielleicht können wir da was sehen.

[papa]

Bestünde evtl. bei der AskSIn++-Library die Möglichkeit, die Sendefrequenz zu verändern? Müsste evtl. ein zusätzliches Register gesetzt werden oder irgendwas wird falsch initialisiert?

Man kann wahrscheinlich alles machen. Aber dazu müssten wir erst mal ganz genau wissen, wo das Problem wirklich liegt und wie es zu fixen ist.

[jp112sdl]

Das könnten wir auch direkt in die Lib einbauen. Das Register ist auf jeden Fall schon definiert. Soll bei Off die Led gar nichts mehr machen oder nur die Signalisierung beim Senden/Empfangen abgeschalten werden ?

Original HM Devices deaktivieren die LED nur beim Senden.
Beim Anlernen/Reset/Init blinkt sie trotzdem.

[papa]

Original HM Devices deaktivieren die LED nur beim Senden.
Beim Anlernen/Reset/Init blinkt sie trotzdem.

Beim Senden wird das ledMode Register jetzt beachtet. Für alle Geräte, welche dieses Register nicht haben, ist der Default auf "On" gesetzt.

[scuba]

Hallo zusammen,

Ich würde gerne die Tasten meines HM-LC-Dim1TPBU-FM für zusätzliche Schaltvorgänge verwenden. Die Möglichkeit den Aktorstatus mit "notifys" zu verarbeiten ist mir zwar bekannt allerdings für meinen Anwendungsfall nicht brauchbar.

Anders als beim HM-LC-Dim1PWM-CV handelt es sich hier ja um einen Phasenabschnittdimmer (Nullduchgangssynchronisation) mit zusätzlicher Temperaturüberwachung über einen NTC (103AT-2) und Überstromerkennung. Soweit ich das gesehen habe ist das soweit (noch?) nicht in AskSin++ implementiert. Gibt's eventuell schon Bestrebungen oder Ansätze für eine Umsetzung ?

lg

[papa]

Ich nicht

[Tom Major]

Beim Senden wird das ledMode Register jetzt beachtet. Für alle Geräte, welche dieses Register nicht haben, ist der Default auf "On" gesetzt.

Sehr gut.
Auf Sketch Seite muss ich nur dafür sorgen das DREG_LEDMODE in der List0 erscheint, das wars, korrekt?
(Und schauen das die die xml und Perl scripte das Register berücksichtigen).

[papa]

Genau - einfach das DREG_LEDMODE mit in die List0-Definition aufnehmen und in der defaults() Methode auf On (also 1) stellen.

[DeepCore]

Hallo zusammen!

...mit in die List0-Definition aufnehmen ...

Wo kann ich diese Definitionen finden? Ich vermute mal, dass die aus den Homematic XML-Dateien generiert wurden/werden, oder?