AskSin++ Library

papa · 04 November 2016, 11:29:07

Hast Du auch den Sketch selber aktualisiert ? Das Handling ist nicht in der Lib.

lech · 04 November 2016, 15:25:55

ZitatHast Du auch den Sketch selber aktualisiert ? Das Handling ist nicht in der Lib.

Ja, ich habe den AskSinPP-master Ordner komplett gelöscht, vom Github neu runtergeladen und die zip-Datei in der Arduino-IDE komplett neu eingebunden. Dann sieht man auch die Beispiel-Sketches. So habe ich schon immer gemacht.
Was ich noch nicht getestet habe, die Platine wird durch den UART-Adapter (FTDI) eingespeist. Vielleicht sollte ich den Adapter wegnehmen und extern einspeisen...
Was mir noch aufgefallen ist, es kommen keine Fremdmeldungen, trotz auskommentierter Zeile im MultiChanneldevice.h.
Der HM-LC-SWX-SM lässt sich leider mit der CCU nicht pairen. Hier kommen aber die Fremdmeldungen an!

Warum CCU2?
Ich bin vor 2 Jahren umgestiegen von FHEM auf Raspberrymatic(CCU Emulator auf Raspberry), weil die Programmierung und Unübersichtlichkeit von FHEM für einen Nichtprogrammierer ziemlich problematisch sind. Selbst wenn du dich eingearbeitet und alles eingestellt hast, nach einem halben Jahr muss man wieder von vorne anfangen.

Momentan brauche ich einen Sketch für meine Türklingel. Die Hardware dazu habe selber auf einer Platine zusammengelötet und nutze einen Sketch von Trilu (HM_LC_SW1_BA_PCB). Das funktioniert soweit, nur die Reaktionszeit ist sehr lang und wenn man den Taster mehrmals drückt, dann geht da gar nichts mehr.
Deswegen möchte ich deinen HM-RC-4 in Kombination mit der CCU zum Laufen bekommen.
Ich müsste vielleicht die Dinger auf einem Breadboard neu aufbauen und nochmal testen

Dietmar63 · 04 November 2016, 18:20:10

wird das Batteriesignal schon in den Nachrichten weitergegeben.
Es wird emittelt, aber wie wird es zurückgegeben.

in FHEM gibt es folgenden Code:
würde ich so interpretieren im AcK_status oder Info_Status muss das höchste bit 0x80 im dritten Element (err) gesetzt sein.
Da die sendAck() alle in Mutichanneldevice gesendet werden kann das Gerät nicht auf batterie aus HM-ES-TX-WM.ino zugreifen.

muss vielleicht dieses bit gesetzt werden:

Code Auswählen

RPTEN = 0x80, // set in every message. Meaning?

Code Auswählen


  elsif($mh{st} eq "powerSensor") {############################################
    if (($mh{mTyp} eq "0201") ||  # handle Ack_Status
        ($mh{mTyp} eq "1006")) {  #    or Info_Status message here

      my ($chn,$val,$err) = (hex($mI[1]),hex($mI[2])/2,hex($mI[3]));
      $chn = sprintf("%02X",$chn&0x3f);
      my $chId = $mh{src}.$chn;
      $mh{shash} = $modules{CUL_HM}{defptr}{$chId}
                             if($modules{CUL_HM}{defptr}{$chId});
                             
      push @evtEt,[$mh{devH},1,"battery:".(($err&0x80)?"low"  :"ok"  )];

      push @evtEt,[$mh{shash},1,"state:$val"];

papa · 05 November 2016, 17:51:23

Das Battery-Bit wird von der flags() Methode im Channel zurück gegeben. Diese Methode wird bei sendAck(Message,Channel) und sendInfoActuatorStatus() ausgewertet. Man müsste eigentlich nur ab und zu sendInfoActuatorStatus() aufrufen.

papa · 05 November 2016, 17:57:59

Zitat von: lech am 04 November 2016, 15:25:55
Ja, ich habe den AskSinPP-master Ordner komplett gelöscht, vom Github neu runtergeladen und die zip-Datei in der Arduino-IDE komplett neu eingebunden. Dann sieht man auch die Beispiel-Sketches. So habe ich schon immer gemacht.
Was ich noch nicht getestet habe, die Platine wird durch den UART-Adapter (FTDI) eingespeist. Vielleicht sollte ich den Adapter wegnehmen und extern einspeisen...
Was mir noch aufgefallen ist, es kommen keine Fremdmeldungen, trotz auskommentierter Zeile im MultiChanneldevice.h.

Aber es ging doch schon mal was. Der FTDI sollte reichen.

Zitat von: lech am 04 November 2016, 15:25:55
Der HM-LC-SWX-SM lässt sich leider mit der CCU nicht pairen. Hier kommen aber die Fremdmeldungen an!

Da war noch der SubType falsch. Habe ich gerade geändert und eingecheckt.

Zitat von: lech am 04 November 2016, 15:25:55
Ich müsste vielleicht die Dinger auf einem Breadboard neu aufbauen und nochmal testen

Das ist sicherlich keine schlechte Idee.

Dietmar63 · 05 November 2016, 18:45:59

Status Batterie: Werde ich mal probieren.
Die Messwerte sehen doch ganz gut aus - oder?

Das fertige Lötwerk ist jetzt so empfindlich, dass ich Abschirmen muss. Selbst die Wärmestrahlung meiner Hand oder das Nachglimmen einer ausgeschalteten Taschenlampe erzeugt Interrupts. Auf dem Breadboard war das nicht so heftig. Aber gut es läuft.

Weiterhin benötigt das Gesamtsystem 0,6 mA. Dafür scheint der Lm358 verantwortlich zu sein. Ohne ihn liegt der Verbrauch bei 0.046 mA. Wenn jemand einen Tipp hat wie man dem oamp den Durst abgewöhnen kann, her mit dem Tipp.

micky0867 · 08 November 2016, 20:41:39

Lötwerk?
Das sieht aber so aus, als hättest du gar nicht gelötet, oder?

Btw: womit hast du den Verbrauch gemessen?

Dietmar63 · 12 November 2016, 15:27:58

Zu dem Zeitpunkt hatte ich noch nichts verlötet. Trockenentwurf
Ganz normales Multimeter - Voltcraft

Habe herausgefunden, dass das Framework hier nach jedem Powerdown ersteinmal das Funkmodul einschaltet. Für mein zweites Projekt eine Helligkeitssensor analog dem Wettersensor universal, will ich ja nur alle drei Minuten wirklich senden. Deshalb schalte ich erst kurz vorm Senden das Modul an. Benötigt so nur 0,090 mA. Temperatur sensor ist noch nicht angekommen. Ich hoffe ich kann ihn noch irgendwie unterbringen. Das Gehäuse ist recht klein.

Code Auswählen



 2016.11.12 15:35:27 3: HM_995678: luminosity: 751 -> 9
2016.11.12 15:32:31 3: HM_995678: luminosity: 685 -> 9
2016.11.12 15:29:35 3: HM_995678: luminosity: 770 -> 9
2016.11.12 15:26:39 3: HM_995678: luminosity: 731 -> 9
2016.11.12 15:24:59 1: No Logdevice Jahresverbrauch

2016.11.12 15:23:43 3: hm2 return value: Undefined subroutine &main::Int called at (eval 1697) line 1.
2016.11.12 15:20:47 3: HM_995678: luminosity: 817 -> 9.67419226814568
2016.11.12 15:20:36 1: No Logdevice Jahresverbrauch
2016.11.12 15:17:50 3: HM_995678: luminosity: 822 -> 9.68299458368168
2016.11.12 15:14:54 3: HM_995678: luminosity: 862 -> 9.7515440590891
2016.11.12 15:11:58 3: HM_995678: luminosity: 923 -> 9.85018683764577
2016.11.12 15:09:02 3: HM_995678: luminosity: 1019 -> 9.99293833616581
2016.11.12 15:06:06 3: HM_995678: luminosity: 1582 -> 10.6275338844728
2016.11.12 15:03:10 3: HM_995678: luminosity: 2341 -> 11.192909219112
2016.11.12 15:00:14 3: HM_995678: luminosity: 2593 -> 11.3404064908533
2016.11.12 14:57:18 3: HM_995678: luminosity: 2776 -> 11.4387918525783
2016.11.12 14:54:22 3: HM_995678: luminosity: 3283 -> 11.680799034573
2016.11.12 14:51:26 3: HM_995678: luminosity: 3873 -> 11.9192357860283
2016.11.12 14:48:29 3: HM_995678: luminosity: 3909 -> 11.9325838692893
2016.11.12 14:45:33 3: HM_995678: luminosity: 3930 -> 11.940313597146
2016.11.12 14:43:32 1: No Logdevice Jahresverbrauch
2016.11.12 14:42:37 3: HM_995678: luminosity: 4108 -> 12.0042204663182
2016.11.12 14:39:41 3: HM_995678: luminosity: 4183 -> 12.030322282644
2016.11.12 14:36:45 3: HM_995678: luminosity: 4254 -> 12.0546043179607
2016.11.12 14:33:49 3: HM_995678: luminosity: 4359 -> 12.089781488354
2016.11.12 14:30:53 3: HM_995678: luminosity: 4521 -> 12.142426202319
2016.11.12 14:27:56 3: HM_995678: luminosity: 4873 -> 12.2505945071923
2016.11.12 14:25:00 3: HM_995678: luminosity: 5102 -> 12.3168471836025
2016.11.12 14:22:04 3: HM_995678: luminosity: 5157 -> 12.3323163301992
2016.11.12 14:19:08 3: HM_995678: luminosity: 5191 -> 12.3417967723918
2016.11.12 14:16:12 3: HM_995678: luminosity: 6198 -> 12.5975870395862
2016.11.12 14:13:16 3: HM_995678: luminosity: 6790 -> 12.7291958591321

Dietmar63 · 12 November 2016, 20:29:52

habe folgendes Problem:

durch die Nutzung diverser Libraries steigt der Speicherbedarf schnell stark an.
Jetzt würde ich gern wissen was wie zum Anstieg beiträgt, finde aber nicht viel dazu.

Mit avr-size -x *.o
bekomme ich folgende Liste heraus. Kann jemand das interpretieren?

Kann man irgendwie verhindern, dass so fette Bibliotheken wie WString oder Tone nicht genutzt werden müssen. Ich habe keine Ahnung wodurch sie eingebunden werden.
Auf dem ersten Blick benötigt man nicht so viel von LowPower und TSL2561. Vielleicht lassen sich abgespeckte Versionen aufbauen und verwenden.

Hat jemand von Euch da Erfahrung?

Code Auswählen


    0x0     0x0     0x0       0       0 ./core/CDC.cpp.o
    0x0     0x0     0x0       0       0 ./core/HardwareSerial1.cpp.o
    0x0     0x0     0x0       0       0 ./core/HardwareSerial2.cpp.o
    0x0     0x0     0x0       0       0 ./core/HardwareSerial3.cpp.o
    0x0     0x0     0x0       0       0 ./core/PluggableUSB.cpp.o
    0x0     0x0     0x0       0       0 ./core/USBCore.cpp.o
    0x2     0x0     0x0       2       2 ./core/hooks.c.o
    0x0     0x1     0x4       5       5 ./libraries/AskSinPP/AccurateSleep.cpp.o
    0x8     0x0     0x0       8       8 ./core/abi.cpp.o
   0x10     0x0     0x0      16      10 ./core/new.cpp.o
   0x10     0x0     0x3      19      13 ./libraries/AskSinPP/HMID.cpp.o
   0x28     0x0     0x0      40      28 ./core/main.cpp.o
   0x4e     0x0     0x6      84      54 ./libraries/TimerOne/TimerOne.cpp.o
   0x56     0x0     0x0      86      56 ./libraries/AskSinPP/Radio_ProMini.cpp.o
   0x8a     0x0     0x0     138      8a ./core/wiring_pulse.S.o
   0xe8     0x0     0x0     232      e8 ./core/wiring_shift.c.o
   0xfe     0x1     0x0     255      ff ./core/wiring_analog.c.o
  0x102     0x4     0x0     262     106 ./core/WInterrupts.c.o
  0x10c     0x0     0x1     269     10d ./libraries/AskSinPP/EEProm.cpp.o
  0x12a     0x0     0x0     298     12a ./core/WMath.cpp.o
  0x177     0x0    0x10     391     187 ./libraries/AskSinPP/Activity.cpp.o
  0x1a4     0x0     0x6     426     1aa ./core/IPAddress.cpp.o
  0x1b3     0x0     0x0     435     1b3 ./libraries/AskSinPP/Device.cpp.o
  0x1d6     0x0     0x0     470     1d6 ./libraries/AskSinPP/SwitchStateMachine.cpp.o
  0x1da     0x0     0x0     474     1da ./core/wiring_pulse.c.o
  0x1dc     0x0     0x0     476     1dc ./core/wiring_digital.c.o
  0x14c     0x0    0x9d     489     1e9 ./core/HardwareSerial0.cpp.o
  0x1ee     0x0     0x9     503     1f7 ./core/wiring.c.o
  0x2f0     0x0     0x0     752     2f0 ./core/HardwareSerial.cpp.o
  0x32d     0x0    0x1a     839     347 ./libraries/AskSinPP/Led.cpp.o
  0x32a     0x0    0x56     896     380 ./libraries/Wire/Wire.cpp.o
  0x490     0x0     0x0    1168     490 ./libraries/AskSinPP/SwitchList3.cpp.o
  0x492     0x0    0x6e    1280     500 ./libraries/Wire/utility/twi.c.o
  0x541     0x1    0x15    1367     557 ./core/Tone.cpp.o
  0x5ca     0x0     0x1    1483     5cb ./libraries/Low-Power/LowPower.cpp.o
  0x61f     0x0     0x0    1567     61f ./core/Print.cpp.o
  0x660     0x0     0x8    1640     668 ./libraries/AskSinPP/AlarmClock.cpp.o
  0x6dd     0x0     0x0    1757     6dd ./core/Stream.cpp.o
  0x80c     0x0     0x0    2060     80c ./libraries/TSL2561/TSL2561.cpp.o
  0x7cf     0x0    0x4f    2078     81e ./libraries/AskSinPP/Radio.cpp.o
 0x13a1     0x0     0x1    5026    13a2 ./core/WString.cpp.o
 0x24aa     0x0    0xe4    9614    258e ./sketch/HM-WDS10-TH-O.ino.cpp.o

papa · 13 November 2016, 08:57:20

Das ist nur die Größe der Object-File. Der Linker sollte nur die wirklich benötigten Teile in das Image aufnehmen. Du kannst ja mal die Debug-Ausgaben abschalten. Einfach in Debug.h ein "define NDEBUG" einfügen.

Dietmar63 · 13 November 2016, 18:41:46

Gilt das auch für die Methoden einer Bibliothek, die nicht aufgerufen werden? Gerade die Verwendung von late Binding in C++ führt dazu, dass der Compiler nicht genau vorhersagen kann, was er alles binden muss.

Kann man solche Details irgendwo her bekommen. Noch habe ich von der Größe her keine Probleme, aber wenn noch weitere Bibliotheken benötige, hätte ich gern ein Verfahren effektiv abzuspecken.

Gibt es eine Möglichkeit den Assemblercode zu erzeugen? Eventuell mit der Größe der einzelnen Methode?

Danke!

papa · 14 November 2016, 16:02:19

Zitat von: Dietmar63 am 13 November 2016, 18:41:46
Gilt das auch für die Methoden einer Bibliothek, die nicht aufgerufen werden? Gerade die Verwendung von late Binding in C++ führt dazu, dass der Compiler nicht genau vorhersagen kann, was er alles binden muss.

Der Linker packt alles rein, was potientiell genutzt werden kann, weil es irgendwo im Code referenziert wird. Da gehören natürlich die virtuellen Methoden, die in der VirtualMethodTable stehen, immer dazu. Deshalb habe ich an vielen Stellen Templates benutzt, da das der Compiler beim übersetzen schon komplett auflösen kann. Allerdings kann es dann auch zu Codedublizierungen kommen, wenn ein Template häufig benutzt wird.
Irgendwas ist halt immer.

Zitat von: Dietmar63 am 13 November 2016, 18:41:46
Kann man solche Details irgendwo her bekommen. Noch habe ich von der Größe her keine Probleme, aber wenn noch weitere Bibliotheken benötige, hätte ich gern ein Verfahren effektiv abzuspecken.

Gibt es eine Möglichkeit den Assemblercode zu erzeugen? Eventuell mit der Größe der einzelnen Methode?

Schau Dir mal avr-objdump an. Damit kriegt man viel raus.
Vielleicht kann der Linke auch noch was zusätzliches generieren, was er wo im Image plaziert hat. Das wäre sicherlich die besten Infos ergeben. Keine Ahnung, ob da was geht.

Dietmar63 · 01 Dezember 2016, 21:49:29

ich probiere einen Bewegungsmelder zu bauen

Code Auswählen


sending peer events ...
<- 0D 01 A0 41 99 45 67 27 10 00 01 01 14 B0 
waitAck: 00
<- 0D 01 A0 41 99 45 67 27 10 00 01 01 14 B0 
waitAck: 00
<- 0D 01 A0 41 99 45 67 27 10 00 01 01 14 B0 
waitAck: 00
<- 0D 01 A0 41 99 45 67 27 10 00 01 01 14 B0 
waitAck: 00
<- 0D 01 A0 41 99 45 67 27 10 00 01 01 14 B0 
waitAck: 00
<- 0D 01 A0 41 99 45 67 27 10 00 01 01 14 B0 
waitAck: 00

kann es sein, dass hier ein Fehler vorliegt. Ich habe nur mit der Zentrale gepairt.
Über

Code Auswählen


      Serial << "sending peer events ...\n";
      device().sendPeerEvent(msg,*this);

wird dreimal versucht eine Nachricht abzusetzen, obwohl kein peer gepairt ist.
Habe ich was falsch verstanden?

papa · 02 Dezember 2016, 08:03:37

Das sieht so aus, als wären noch Daten im EEProm von einem vorherigen Sketch. Mach mal nen RESET - Config-Taster mehr als 6 Sekunden drücken. Dann werden alle Channels neu initialisiert. Danach muss neu angelernt werden.

Ich muss mir mal Gedanken machen, wie ich die Initialisierung des EEProm verbessern kann, so daß Änderungen an der Channelkonfiguration eine neue Initialisierung auslösen.

Dietmar63 · 05 Dezember 2016, 22:21:23

versuche den HM-SEC-MDIR zum Laufen zu bringen.

Habe ein Problem mit minInterval.
Das Feld wird mit minInterval(4) initialisiert.

Der Inhalt des Feldes wird mit pload[1] = (next+4) << 4; an fhem übergeben.

minInterval() liefert aber nicht 4 sondern 7 zurück.
Das führt dann dazu, dass in fhem nicht 240s sondern 1920s angezeigt wird.

Irgendwo funktioniert da etwas nicht. Verstehe die bit-Funktionen in setByte/getByte nicht.