Autor Thema: AskSin++ Library  (Gelesen 175021 mal)

jp112sdl

  • Gast
Antw:AskSin++ Library
« Antwort #675 am: 25 Februar 2018, 14:23:50 »
Sorry hätte mehr infos geben können:

Pro mini 8Mhz mit CC1101 Funke

Und auch 8 MHz als Board ausgewählt beim Upload? Ich hatte dein beschriebenes Phänomen auch mal. Lag irgendwie an falscher Frequenzauswahl


Gesendet von iPhone mit Tapatalk

Offline andirs

  • New Member
  • *
  • Beiträge: 20
Antw:AskSin++ Library
« Antwort #676 am: 25 Februar 2018, 14:41:50 »
In der Arduino IDE ist auch 8 Mhz ausgewählt, trotzdem danke :)

Edit: Ah schon gut, hatte ein paar Zeilen in der .ino auskommentiert von denen ich dachte dass Sie nichts mit dem Anlernen zu tun haben. Habe diese wieder einkommentiert und jetzt gehts :)
« Letzte Änderung: 25 Februar 2018, 17:26:24 von andirs »

Offline papa

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1739
Antw:AskSin++ Library
« Antwort #677 am: 25 Februar 2018, 18:39:07 »
Wenn Du uns jetzt noch verräts, wie der Code aussieht oder welches Example Du nutzt, könnten wir Dir auch vielleicht helfen.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Offline Tom Major

  • Sr. Member
  • ****
  • Beiträge: 532
    • TomMajor@github
Antw:AskSin++ Library
« Antwort #678 am: 25 Februar 2018, 19:15:28 »
Ich habe jetzt meine CC1101 bekommen und als erstes das Wassermelder example (HM-SEC-WDS) mal aufgebaut und getestet. Was soll ich sagen, funktionierte auf Anhieb, screenshots vom Prototyp und CCU2 Gerät im Anhang. Die Ruhestromaufnahme liegt bei sehr guten 4 uA.

Vielen Dank an papa und natürlich auch an die Ersteller der vorherigen AskSin libraries für diese Arbeit! Ein ganz toller HomeMatic Baukasten. Eigene Modifikationen sind, wenn man nicht so der C++ class template Programmierer crack ist, am Anfang etwas schwierig, aber man findet sich rein.

Bin auch aktuell mit papa im Kontakt, um die ThreeStateChannel Klasse etwas universeller zu gestalten, ich möchte für den Wassermelder Erkennung ADC statt GPIO verwenden und das meassure Intervall braucht bei mir auch nicht 1sec zu sein, sondern z.B. 1min, das reicht auch und spart Batteriestrom.
Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker

Offline LuBeDa

  • Full Member
  • ***
  • Beiträge: 156
Antw:AskSin++ Library
« Antwort #679 am: 25 Februar 2018, 20:02:18 »
AskSin++ Library oder nur MySensors

Hallo,
ich möchte mir einen 4fach Sensor bauen, er soll einen BME280 für Temperatur, Luftfeuchte und Luftdruck haben und einen PIR Bewegungsmelder.

Für mein Project fände ich eine "Homematic" Lösung sehr cool, weil man den PIR z.B. direkt mit meinen Homematic Aktoren peeren könnte.

Leider gibt es außer dem Sourcecode von pa-pa und jp112sdl auf github scheinbar noch keine Doku.

Weil ich quasi einen neuen Gerätetyp erzeuge ("Wettersensor" mit PIR) gibt es auch kein Source-Beispiel auf dem man aufbauen kann.

Da gibt es zwei Baustellen. Einmal muss man einen Arduino Sketch erstellen der drei Messwerte und einen "Schalter" nach FHEM übermittelt
und zweitens fehlt dann das passende Modul in FHEM oder in CCU2/RaspberryMatic.

Sehe ich das so richtig?

Gibt es vielleicht irgendwelche Wikis, Blogs oder ausgewählte Foreneinträge die den Einstieg der AskSin++ Programmierung etwas ausführlicher beschreiben?

Danke Ludger

Offline papa

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1739
Antw:AskSin++ Library
« Antwort #680 am: 25 Februar 2018, 21:03:00 »
AskSin++ Library oder nur MySensors

Hallo,
ich möchte mir einen 4fach Sensor bauen, er soll einen BME280 für Temperatur, Luftfeuchte und Luftdruck haben und einen PIR Bewegungsmelder.

Für mein Project fände ich eine "Homematic" Lösung sehr cool, weil man den PIR z.B. direkt mit meinen Homematic Aktoren peeren könnte.

Leider gibt es außer dem Sourcecode von pa-pa und jp112sdl auf github scheinbar noch keine Doku.

Weil ich quasi einen neuen Gerätetyp erzeuge ("Wettersensor" mit PIR) gibt es auch kein Source-Beispiel auf dem man aufbauen kann.

Da gibt es zwei Baustellen. Einmal muss man einen Arduino Sketch erstellen der drei Messwerte und einen "Schalter" nach FHEM übermittelt
und zweitens fehlt dann das passende Modul in FHEM oder in CCU2/RaspberryMatic.

Sehe ich das so richtig?

Ja

Gibt es vielleicht irgendwelche Wikis, Blogs oder ausgewählte Foreneinträge die den Einstieg der AskSin++ Programmierung etwas ausführlicher beschreiben?

Nein - nur was hier steht
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Offline Tom Major

  • Sr. Member
  • ****
  • Beiträge: 532
    • TomMajor@github
Antw:AskSin++ Library
« Antwort #681 am: 26 Februar 2018, 01:30:34 »
Bin auch aktuell mit papa im Kontakt, um die ThreeStateChannel Klasse etwas universeller zu gestalten, ich möchte für den Wassermelder Erkennung ADC statt GPIO verwenden und das meassure Intervall braucht bei mir auch nicht 1sec zu sein, sondern z.B. 1min, das reicht auch und spart Batteriestrom.
wow, das ging schnell, papa hat sich meinen pull-request angeschaut, das ganze so geändert das es rückwärtskompatibel ist und eingecheckt. Habe es gerade getestet, ich kann jetzt nur mit Änderungen im sketch den Wassermelder mit ADC Messwerten füttern und das Messintervall auch vom sketch aus konfigurieren.
Danke für die schnelle Bearbeitung. Bei Interesse kann ich das erweiterte sketch für die examples im Repo anbieten.
Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker

Offline Tom Major

  • Sr. Member
  • ****
  • Beiträge: 532
    • TomMajor@github
Antw:AskSin++ Library
« Antwort #682 am: 26 Februar 2018, 01:42:02 »
AskSin++ Library oder nur MySensors
Hallo,
ich möchte mir einen 4fach Sensor bauen, er soll einen BME280 für Temperatur, Luftfeuchte und Luftdruck haben und einen PIR Bewegungsmelder.
Da gibt es zwei Baustellen. Einmal muss man einen Arduino Sketch erstellen der drei Messwerte und einen "Schalter" nach FHEM übermittelt
und zweitens fehlt dann das passende Modul in FHEM oder in CCU2/RaspberryMatic.

Die erste Baustelle erscheint mir machbar. Du nimmst z.B. das HM-WDS100-C6-O-2 example, implementierst deine PIR Messungen im sketch und passt dann die payload so an dass der PIR in einem von dir nicht benötigten Datenfeld übertragen wird. Dann hättest Du ein kompatibles Gerät in der ccu2 oder FHEM mit teilweise geänderten Messgrößen. Und die 2. Baustelle fällt erst mal weg.

Wenn das funktioniert könnte man sich später an das neu generieren (über eine xml Datei glaub ich) eines HM devices machen, ob das aber von der ccu2 problemlos akzeptiert wird bin ich überfragt.
Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker

Offline andirs

  • New Member
  • *
  • Beiträge: 20
Antw:AskSin++ Library
« Antwort #683 am: 26 Februar 2018, 15:58:17 »
Hallo danke nochmal papa, wie ich im Edit geschrieben hatte habe ich das Problem lösen können.
Allerdings habe ich eine neue Frage/Verständnisproblem:

Ich habe mir mit deiner Library und einem Arduino Pro mini 8 Mhz und dem CC1101 modul einen eigenen UniSensor gebaut, welcher Temp/Feuchte über einen DHT22 und die Helligkeit über einen analogen Sensor misst. Soweit klappt die Messwerterfassung und das Anlernen und Übermitteln der Messages an die Zentrale.

Problematisch ist die Häufigkeit mit der die Nachrichten gesendet werden. Ich habe das Example vom HM-WDS10-TH-O herangezogen und dort finden sich folgende Zeilen, die die Zeit zur nächsten Nachricht bestimmen (zumindest verstehe ich das so):

 
    virtual void trigger (__attribute__ ((unused)) AlarmClock& clock) {
    // wait also for the millis
    if( millis != 0 ) {
      tick = millis2ticks(millis);
      millis = 0; // reset millis
      sysclock.add(*this); // millis with sysclock
    }
    else {
      uint8_t msgcnt = device().nextcount();
      measure();
      msg.init(msgcnt,dht11.temperature(),dht11.humidity(),device().battery().low());
      device().sendPeerEvent(msg,*this);

      // reactivate for next measure
      HMID id;
      device().getDeviceID(id);
      uint32_t nextsend = delay(id,msgcnt);
      tick = nextsend / 1000; // seconds to wait
      millis = nextsend % 1000; // millis to wait
      rtc.add(*this);
    }
}

// here we calc when to send next value
  uint32_t delay (const HMID& id,uint8_t msgcnt) {
    uint32_t value = ((uint32_t)id) << 8 | msgcnt;
    value = (value * 1103515245 + 12345) >> 16;
    value = (value & 0xFF) + 480;
    value *= 250;

    DDEC(value / 1000);DPRINT(".");DDECLN(value % 1000);

    return value;
}

Wenn ich das richtig recherchiert habe kommt das daher um den HM-CC-RT-DN pairen zu können. Bei mir führt das allerdings dazu, dass etwa alle 1-2 s eine Nachricht gesendet wird. Das ist denke ich beim Batteriebetrieb viel zu oft. Einen HM-CC-RT-DN würde ich auch gerne pairen, das schlägt aber (noch) fehl. Liegt das ggf. an einer schlecht gewählten ID? Am messagecount kann ich ja nichts ändern.

// define all device properties
const struct DeviceInfo PROGMEM devinfo = {
    {0x11,0x12,0x13},          // Device ID
    "USLR111111",              // Device Serial
    {0xF1,0x01},              // Device Model
    0x10,                      // Firmware Version
    as::DeviceType::THSensor, // Device Type
    {0x01,0x01}                // Info Bytes
};

Wie oft in etwa sollte denn eine Nachricht normalerweise gesendet werden?

Was mir auch noch aufgefallen ist, dass in meinem Code Allg. ein Zeit Problem existiert. Der folgende Code sagt ja dass die Batt einmal pro Stunde gemessen werden soll. Laut meinem ser. Monitor passiert das aber eher alle paar Sekunden.

// measure battery every 1h
battery.init(60UL*60,rtc);

Hier ein Ausschnitt aus dem Seriellen Monitor:

AskSin++ V2.1.4 (Feb 26 2018 15:37:02)
Address Space: 32 - 70
CC init1
CC Version: 14
 - ready
Bat: 74
Try #: 1
T: 212 H: 44 B: 79
<- 0D 01 84 70 111213 000000 00 D4 2C 4F  - 3428
136.500
T: 212 H: 44 B: 78
<- 0D 02 84 70 111213 000000 00 D4 2C 4E  - 3756
122.0
T: 211 H: 44 B: 78
<- 0D 03 84 70 111213 000000 00 D3 2C 4E  - 4081
171.750
T: 211 H: 44 B: 77
<- 0D 04 84 70 111213 000000 00 D3 2C 4D  - 4413
157.250
T: 211 H: 44 B: 78
<- 0D 05 84 70 111213 000000 00 D3 2C 4E  - 4743
142.750
T: 211 H: 44 B: 78
<- 0D 06 84 70 111213 000000 00 D3 2C 4E  - 5070
128.500
T: 211 H: 44 B: 77
<- 0D 07 84 70 111213 000000 00 D3 2C 4D  - 5398
178.0
T: 211 H: 44 B: 77
<- 0D 08 84 70 111213 000000 00 D3 2C 4D  - 5730
163.500
T: 212 H: 44 B: 77
<- 0D 09 84 70 111213 000000 00 D4 2C 4D  - 7008
149.250
T: 211 H: 43 B: 76
<- 0D 0A 84 70 111213 000000 00 D3 2B 4C  - 7335
134.750
T: 211 H: 43 B: 76
<- 0D 0B 84 70 111213 000000 00 D3 2B 4C  - 7663
120.250
T: 211 H: 43 B: 76
<- 0D 0C 84 70 111213 000000 00 D3 2B 4C  - 7989
169.750
Bat: 89
T: 211 H: 43 B: 76
<- 0D 0D 84 70 111213 000000 00 D3 2B 4C  - 8325
155.500
T: 211 H: 43 B: 75
<- 0D 0E 84 70 111213 000000 00 D3 2B 4B  - 9601
141.0
T: 211 H: 43 B: 75
<- 0D 0F 84 70 111213 000000 00 D3 2B 4B  - 9930
126.500
T: 211 H: 43 B: 76
<- 0D 10 84 70 111213 000000 00 D3 2B 4C  - 10256
176.250
T: 210 H: 43 B: 79
<- 0D 11 84 70 111213 000000 00 D2 2B 4F  - 10590
161.750

Mein .ino hab ich mal mit angehangen.

Vielen Dank.

Offline Tom Major

  • Sr. Member
  • ****
  • Beiträge: 532
    • TomMajor@github
Antw:AskSin++ Library
« Antwort #684 am: 26 Februar 2018, 16:32:44 »
Hast Du einen 32kHz Quarz an XTAL? Weil dein sketch mit rtc arbeitet.

Alternativ könntest Du die rtc testweise aus dem sketch rausnehmen und in trigger mal sowas mit sysclock versuchen, um z.B. alle 2min zu senden:
set(seconds2ticks(60UL*2));
clock.add(*this);
// und hal.activity.savePower anpassen nicht vergessen
Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline andirs

  • New Member
  • *
  • Beiträge: 20
Antw:AskSin++ Library
« Antwort #685 am: 26 Februar 2018, 18:19:05 »
Danke für den Tipp, einen 32khz quarz habe ich nicht. Nach ein wenig recherche werde ich mir wohl mal welche aus China bestellen (müssen) :)

Brauche ich dazu noch etwas? Würden es diese tun? https://de.aliexpress.com/item/Free-shipping-10PCS-32-000MHZ-32-000M-32M-32MHZ-32-MHZ-Crystal-Oscillator-49S-NEW-and/32720698559.html?isOrigTitle=true

Danke

Offline Tom Major

  • Sr. Member
  • ****
  • Beiträge: 532
    • TomMajor@github
Antw:AskSin++ Library
« Antwort #686 am: 26 Februar 2018, 18:24:03 »
Du hast einen 32 MHz referenziert, benötigt wird ein 32,768 kHz für die RTC. Den bekommt man ohne Schwierigkeiten bei conrad, reichelt ebay usw.
Ich würde es erst mal ohne RTC nur mit sysclock testen. Für einen Temperatursender der alle paar Minuten aufwacht braucht man wirklich keine RTC, aus meiner Sicht.
Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker

Offline andirs

  • New Member
  • *
  • Beiträge: 20
Antw:AskSin++ Library
« Antwort #687 am: 26 Februar 2018, 19:29:13 »
so wie ich das gelesen habe ist das timing beim pairen mit dem HM-CC-RT-DN schwierig werden könnte ohne den quarz :)
dazu muss wohl auch die berechnung wann der nächste wert gesendet wird beibehalten werden, statt einfach alle 2min zu senden.

Kannst du meinen angehangenen sketch ggf. mal umändern sodass die interne uhr verwendet wird?
ich selbst habs grad kaputt gemacht und jetzt sendet es garnichts mehr :D da ich den sketch inkl. library im prinzip garnicht verstehe (nur wie ich eigene sensoren einbinde) ist das ein schwieriges unterfangen.

danke

Offline Tom Major

  • Sr. Member
  • ****
  • Beiträge: 532
    • TomMajor@github
Antw:AskSin++ Library
« Antwort #688 am: 26 Februar 2018, 19:39:38 »
so wie ich das gelesen habe ist das timing beim pairen mit dem HM-CC-RT-DN schwierig werden könnte ohne den quarz :)
dazu muss wohl auch die berechnung wann der nächste wert gesendet wird beibehalten werden, statt einfach alle 2min zu senden.
Ja, was ich gelesen habe können die HM-CC-RT-DN eine Menge Funkverkehr erzeugen, Burst mode usw.
Aber ich dachte Du wolltest einen HM-WDS10-TH-O nachbauen? Wieso glaubst Du wenn der alle 2min sendet wird das nicht akzeptiert? Hast Du dafür irgendwo einen link zum Nachlesen?

Ich hatte sowie so vor nach dem Wassermelder den HM-WDS10-TH-O als nächstes nachzubauen. Also ich schaue mir das mal heute abend oder morgen an, mit sysclock statt rtc.
Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker

Offline andirs

  • New Member
  • *
  • Beiträge: 20
Antw:AskSin++ Library
« Antwort #689 am: 26 Februar 2018, 19:58:21 »
Danke dir.

Den HM-WDS10-TH-O wollte ich nicht 1zu1 nachbauen, sondern habe den als Vorlage für meinen Sensor genutzt.
Worauf ich hinaus möchte sind Sensoren für den Innenraum die Temp, Feuchte und Helligkeit messen und an die Zentrale senden.
Gleichzeitig soll dieser direkt mit HM-CC-RT-DN gepaired werden, damit dieser auf die Isttemperatur am UniSen regelt und nicht auf seine eigene.
Genau wegen diesem Direktpairing möchte ich möglichst nah bei der Vorlage von papa bleiben, weil er sich sicher was dabei gedacht hat :)