Autor Thema: Fensterdrehgeriffkontakt - Die nächste Runde  (Gelesen 51567 mal)

Offline papa

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1989
Antw:Fensterdrehgeriffkontakt - Die nächste Runde
« Antwort #450 am: 10 August 2021, 21:54:39 »
Quick and dirty ....

Du tauscht die Batteriesensor-Implementierung gegen das Auslesen des TempSensors - Methode current()

https://github.com/pa-pa/HB-Sec-RHS-3/blob/53a1b1d96bb82608659d733a3342fa49a77e5fc7/Sketch/HB-SEC-RHS-3/HB-SEC-RHS-3.ino#L81

Dann änderst Du das Sendeinterval für die zyklischen Nachrrichten im Template

https://github.com/pa-pa/AskSinPP/blob/711842f791a5365f8a928596fca4ab7af4155dd8/ContactState.h#L202


BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Offline Flole

  • New Member
  • *
  • Beiträge: 12
Antw:Fensterdrehgeriffkontakt - Die nächste Runde
« Antwort #451 am: 10 August 2021, 22:27:15 »
Dann verliere ich ja die Batteriespannung, nicht gut ;)

Das später nochmal bei 25 Sensoren zu ändern und die Firmware dann OTA zu korrigieren ist bestimmt auch alles andere als lustig. Ist es denn so kompliziert da eben einen neuen Datenpunkt zu erzeugen, oder gar einfach noch einen neuen Channel? Kann ich nicht gleichzeitig den ThreePinChannel und einen WeatherChannel irgendwie haben? Das ThreeStateDevice hat doch auch einen ChannelCount parameter, nur wie kriege ich den zweiten channel da rein? Dem kann ich ja nur einen ChannelType übergeben.....

Oder aber wenn ich sowieso einen dirty-fix mache: Im trigger vom EventSender in der ContactState.h die Temperatur auslesen und noch appenden und das interval dann einfach im TLEPosition zurückgeben?
« Letzte Änderung: 10 August 2021, 23:14:45 von Flole »

Offline Tom Major

  • Sr. Member
  • ****
  • Beiträge: 592
    • TomMajor@github
Antw:Fensterdrehgeriffkontakt - Die nächste Runde
« Antwort #452 am: 10 August 2021, 23:52:40 »
Eventuell hilft msg.append(), um extra Daten anzuhängen.
Das nutze ich hier beim custom Wassermelder für die Batt.spannung, die das Original-Gerät HM-Sec-WDS-2 nicht hat:
https://github.com/TomMajor/SmartHome/blob/master/HB-Sec-WDS-2/Arduino/HB-Sec-WDS-2/HB-Sec-WDS-2.ino#L89
Also in measure() die Temp. holen, an die msg appenden und natürlich das AddOn für die geänderte Msg. anpassen.
Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker
Hilfreich Hilfreich x 1 Liste anzeigen

Offline papa

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1989
Antw:Fensterdrehgeriffkontakt - Die nächste Runde
« Antwort #453 am: 11 August 2021, 09:24:22 »
Dann verliere ich ja die Batteriespannung, nicht gut ;)

Das später nochmal bei 25 Sensoren zu ändern und die Firmware dann OTA zu korrigieren ist bestimmt auch alles andere als lustig. Ist es denn so kompliziert da eben einen neuen Datenpunkt zu erzeugen, oder gar einfach noch einen neuen Channel? Kann ich nicht gleichzeitig den ThreePinChannel und einen WeatherChannel irgendwie haben? Das ThreeStateDevice hat doch auch einen ChannelCount parameter, nur wie kriege ich den zweiten channel da rein? Dem kann ich ja nur einen ChannelType übergeben.....
Für unterschiedliche Channel brauchst Du ein VirtBaseChannel - da ist an alles virtual und kann unterschiedlich implementiert werden - braucht aber auch mehr Speicher.

https://github.com/pa-pa/AskSinPP/blob/711842f791a5365f8a928596fca4ab7af4155dd8/Channel.h#L361

Am besten Du schaust Dir mal den HB-SW2-SENS an - da sind 2 SwitchChannel und ein StateChannel.

https://github.com/pa-pa/AskSinPP/blob/711842f791a5365f8a928596fca4ab7af4155dd8/examples/custom/HB-SW2-SENS/HB-SW2-SENS.ino#L76

BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Offline Flole

  • New Member
  • *
  • Beiträge: 12
Antw:Fensterdrehgeriffkontakt - Die nächste Runde
« Antwort #454 am: 11 August 2021, 15:14:48 »
Speicher habe ich genug, habe das jetzt mal ausprobiert und sehe im Prinzip nur 2 Probleme (erstmal ;) ):

Im WeatherChannel muss ich irgendwie an dev kommen, aktuell habe ich es so gemacht aber muss es noch initialisieren, wo/wie mache ich das?

class WeatherChannel : public Channel<Hal, WeatherList1, EmptyList, List4, PEERS_PER_CHANNEL, RHSList0>, public Alarm {

    WeatherEventMsg msg;
    int16_t         temp;
    uint16_t        millis;
    WeatherChannel& dev;
    ::OneWire       _oneWire;

public:
    WeatherChannel() : Channel(), Alarm(5), temp(0), millis(0), _oneWire(0) {}
    virtual ~WeatherChannel() {}


    // here we do the measurement
    void measure() {
        DPRINT("Measure...\n");

        _oneWire.reset();
        _oneWire.write(0xCC);    // Select entire BUS
        _oneWire.write(0x44);    // start conversion, use ds.write(0x44,1) with parasite power on at the end

        for(int i = 0; i < 800; i++)
            delayMicroseconds(1000);

        _oneWire.reset();
        _oneWire.write(0xCC);    // Select entire BUS
        _oneWire.write(0xBE);    // Read Scratchpad

        uint8_t data[9];
        for (uint8_t i = 0; i < 9; i++) {    // we need 9 bytes
            data[i] = _oneWire.read();
        }

        if (OneWire::crc8(data, 8) == data[8]) {
            int16_t raw = (data[1] << 8) | data[0];

            if ((raw * 10) / 16 != 850) {
                temp = (raw * 10) / 16;
                DPRINT("T = " + String(temp) + "\n");
            }
            else {
                DPRINT("T INVALID!\n");
            }
        } else {
            DPRINT("DS CRC INVALID!\n");
        }

    }

    virtual void trigger(__attribute__((unused)) AlarmClock& clock) {
        uint8_t msgcnt = device().nextcount();
        // reactivate for next measure
        tick = delay();
        clock.add(*this);
        measure();
        msg.init(msgcnt, temp);
        if (msgcnt % 20 == 1) device().sendPeerEvent(msg, *this); else device().broadcastEvent(msg, *this);
    }

    uint32_t delay() {
        uint16_t _txMindelay = 180;
        _txMindelay = dev.getList1().Sendeintervall();
        if (_txMindelay == 0) _txMindelay = 180;
        return seconds2ticks(_txMindelay);
    }

    void init(int pin) {
        _oneWire.begin(pin);
    }

    void setup(Device<Hal, RHSList0>* dev, uint8_t number, uint16_t addr) {
        Channel::setup(dev, number, addr);
        sysclock.add(*this);
    }

    uint8_t status() const {
        return 0;
    }

    uint8_t flags() const {
        return 0;
    }
};
Vermutlich muss ich sowas ähnliches tun wie
    WeatherChannel(WeatherChannel& d) : Channel(), Alarm(5), temp(0), millis(0), dev(d), _oneWire(0) {}
aber so bekomme ich
Channel.h: 410:18: error: no matching function for call to 'WeatherChannel::WeatherChannel()
   VirtChannel () {}
HB-SEC-RHS-3.ino:246: note  candidate  WeatherChannel  WeatherChannel(WeatherChannel&)
     WeatherChannel(WeatherChannel& d) *: Channel(), Alarm(5), temp(0), millis(0), dev(d), _oneWire(0) {}
   ^~~~~~~~~~~~~~
HB-SEC-RHS-3.ino:246: note    candidate expects 1 argument, 0 provided

Warum ist im configChanged der cycleInfoMsg-Teil auskommentiert?
virtual void configChanged() {
        if ( /*this->getList0().cycleInfoMsg() ==*/ true) {
            DPRINTLN("Activate Cycle Msg");
            sysclock.cancel(cycle);
            cycle.set(CYCLETIME);
            sysclock.add(cycle);
        }
        else {
            DPRINTLN("Deactivate Cycle Msg");
            sysclock.cancel(cycle);
        }
    }
Sieht soweit doch eigentlich richtig aus und als ob das sinnvoll wäre das mit reinzunehmen? Und muss ich von dem configChanged aus noch irgendwas tun um ein eventuell geändertes Sendeintervall von meinem WeatherChannel zu übernehmen? Oder das configChanged vom RHSType dort integrieren falls sich das auf die RHSList0 bezieht?
Im RHSType ist auch ein
    TSDevice::configChanged();
mit drin, sollte ich das auch mit reinnehmen als
        DeviceType::configChanged();
« Letzte Änderung: 11 August 2021, 21:07:11 von Flole »

Offline papa

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1989
Antw:Fensterdrehgeriffkontakt - Die nächste Runde
« Antwort #455 am: 11 August 2021, 21:47:37 »
Mach mal nen neuest Thema auf. Das ist hier doch sehr speziell.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline Flole

  • New Member
  • *
  • Beiträge: 12
Antw:Fensterdrehgeriffkontakt - Die nächste Runde
« Antwort #456 am: 11 August 2021, 22:23:51 »
Hab ich, eine gute Idee. Falls irgendwer mal darüber stolpert und den anderen Thread sucht: https://forum.fhem.de/index.php/topic,122450.0.html

Offline KurtK

  • New Member
  • *
  • Beiträge: 36
Antw:Fensterdrehgeriffkontakt - Die nächste Runde
« Antwort #457 am: 12 August 2021, 10:47:18 »
Hat jemand ne STL-Datei für den Magnethalter und 1,6mm Platinendicke?

In der FreeCad Datei für den Small ist leider kein Magnethalter drin und der in der großen Version skaliert sich nicht automatisch mit, sobald man die Platinendicke auf 1,6mm ändert. (Wurde ein paar Seiten vorher auch schonmal angemerkt)

Hab zum Testen den aus dem Repository genommen, der ist aber auch nur für 1mm Dicke und hat keinen Spacer nach oben. Daher hab ich mir schon die erste Leiterbahn beim testen zerkratzt.

- FHEM auf Intel NUC mit Proxmox -
- FTUI mit FUIP -
- HM, Zigbee,  WLAN -

Offline Maxel

  • New Member
  • *
  • Beiträge: 47
Antw:Fensterdrehgeriffkontakt - Die nächste Runde
« Antwort #458 am: 12 August 2021, 18:24:47 »
Ich habe den Magnethalter oberhalb der Platine plaziert. Darunter war für mich zu wenig Platz. Die Bodenplatte habe seitlich höher geführt. Damit passt die 1,6mm starke Platine gut rein. Die Magnetplatte steckt dann zwischen Platine und Griff.

Gruß Maxel
FHEM auf Banana Pi
CUL V3 (FS20), Homematic, MAX, 1-Wire, Lacrosse (LaCrosseGateway)
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline KurtK

  • New Member
  • *
  • Beiträge: 36
Antw:Fensterdrehgeriffkontakt - Die nächste Runde
« Antwort #459 am: 13 August 2021, 14:09:34 »
Habe den Magnethalter jetzt so gelassen und eine 1mm dicke Abdeckung gedruckt, die zwischen Platine und Griff liegt. Funktioniert bis jetzt problemlos.

- FHEM auf Intel NUC mit Proxmox -
- FTUI mit FUIP -
- HM, Zigbee,  WLAN -

Offline Steffih276

  • New Member
  • *
  • Beiträge: 4
Antw:Fensterdrehgeriffkontakt - Die nächste Runde
« Antwort #460 am: 15 August 2021, 23:05:17 »
Hallo zusammen,

ich möchte mich nun auch endlich mal an dieses Projekt ranwagen, nachdem ich das im letzten Jahr noch etwas auf die lange Bank schieben musste...

Es hat in der Zwischenzeit ja sehr viele Infos gegeben, daher versuche ich einfach mal zusammenzufassen, ob ich richtig starten würde.

Gerber Files nehme ich von hier: https://github.com/pa-pa/HB-Sec-RHS-3/tree/master/gerber_small
Und lasse bei JLCPCB fertig und die Unterseite direkt bestücken.

Anschließend brauche ich noch die Teile aus diesem Posting: https://forum.fhem.de/index.php/topic,109786.msg1169512.html#msg1169512

Sind die SMD Bauteile auch für mich als komplett ungeübte SMD-Löterin machbar? Ich kann bisher nur nicht-SMD Bauteile löten.

Im Erdgeschoss würde ich auch gerne einen Glasbruchmelder mit anschließen. Gibt es dafür Empfehlungen, welchen ich kaufe sollte?

Passt das so, oder habe ich noch etwas wesentliches vergessen / übersehen?

Schöne Grüße
Steffi

Offline KurtK

  • New Member
  • *
  • Beiträge: 36
Antw:Fensterdrehgeriffkontakt - Die nächste Runde
« Antwort #461 am: 16 August 2021, 08:55:17 »
Hallo Steffi,
das klingt alles erstmal gut. Die 2*1mm Magneten sind noch nicht in der Liste.

An das SMD löten habe ich mich auch im Rahmen dieses Projektes das erste mal rangewagt. Mit einer passend dünnen Lötspitze und einer guten Pinzette ist das aber machbar.

Zum Aufspielen des Bootloaders brauchst du noch einen ISP Programmer (USBasp oder Diamex).
Hier würde ich den Diamex vorziehen, da er echte 3,3V liefert (VCC und SPI) und so das Funkmodul auch schon eingelötet werden kann.
Ist hier auch nochmal beschrieben https://asksinpp.de/Grundlagen/04-isp.html#anschluss-des-isp
Jenachdem ob du den Standard Bootloader flasht ist dann auch noch ein FTDI-Programmer notwendig. Dies kann man aber umgehen indem der OTA Bootloader verwendet wird.

 Viele Grüße
- FHEM auf Intel NUC mit Proxmox -
- FTUI mit FUIP -
- HM, Zigbee,  WLAN -

Offline papa

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1989
Antw:Fensterdrehgeriffkontakt - Die nächste Runde
« Antwort #462 am: 16 August 2021, 10:43:00 »
Im Erdgeschoss würde ich auch gerne einen Glasbruchmelder mit anschließen. Gibt es dafür Empfehlungen, welchen ich kaufe sollte?
Der Glasbruchsensor ist nur als Anschluss vorhanden. Die Software unterstützt das bisher nicht.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Offline eki

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1406
Antw:Fensterdrehgeriffkontakt - Die nächste Runde
« Antwort #463 am: 16 August 2021, 10:58:53 »
Ich habe nun ein geflashtes Modul (schmale Version, nur 2 TLEs) und das Ganze scheint auch erst mal zu starten (rote LED blinkt 7 mal, danach rot und grün danach grün).

Mit dem Seriellen Monitor bekomme ich folgendes:


Start App
AskSin++ v5.0.0 (Aug 13 2021 17:01:32)
Address Space: 32 - 102
CC init1
CC Version: 14
 - ready
Pins: 110
Activate Cycle Msg
<- 0E 01 86 10 808E18 000000 06 01 C8 00 00  - 3151
 debounce
 pressed
 released
<- 1A 02 84 00 808E18 000000 22 00 C3 47 49 49 37 32 35 36 34 31 39 80 01 01 00  - 6928

Danach kommt im Monitor nichts mehr. Wenn ich den config button drücke, blinken rot und grün eine Zeitlang, an der CCU kommt aber nichts an. Im Monitor ist dabei auch nichts zu sehen.
Wenn ich den Magneten in die Nähe der TLEs bringe bzw. wieder wegnehme, dann leuchtet die grüne LED auch.

Irgendwelche Tips woran es liegen könnte?

Edit: Beim Drücken des Configbuttons ist doch noch etwas zu sehen, habe die Ausgabe noch mal angepasst.
« Letzte Änderung: 16 August 2021, 13:48:19 von eki »

Offline papa

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1989
Antw:Fensterdrehgeriffkontakt - Die nächste Runde
« Antwort #464 am: 16 August 2021, 21:08:28 »
Ich tippe mal auf ein mangelhaftes Funkmodul.
Hilfe gibt es hier https://asksinpp.de/Grundlagen/FAQ/Fehlerhafte_CC1101.html#ermittlung-der-cc1101-frequenz
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire