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

Offline papa

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1231
Antw:AskSin++ Library
« Antwort #1020 am: 01 Oktober 2018, 18:32:42 »
hm - mir fällt da spontan nichts ein. Bei einem Byte könnte an recht einfach die Set-Message nehmen. Aber 32bit geht so nicht. Da müsste man ein ganz neues Gerät machen inklusive FHEM-Anbindung.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Offline Tom Major

  • Full Member
  • ***
  • Beiträge: 200
    • TomMajor@github
Antw:AskSin++ Library
« Antwort #1021 am: 02 Oktober 2018, 01:20:05 »
@papa
Könnte er nicht einfach im culHmRegDefine des FHEM Scripts die message length einer 'custom' message auf 4 Bytes setzen
s=>4.0und dann im Arduino Sketch bei DEFREGISTER die 4 Bytes definieren und zum 32bit Wert zusammensetzen?
Hacky, aber danach wurde gefragt  ;)
FHEM 5.x auf Raspberry Pi 3 | OWServer mit I2C/DS2482 | 1-Wire 6fach S0-Stromzähler ATtiny/DS2423 Emu. | Heizungs-Mon. mit Firmata (mighty-1284p) | Ölstand-Mon. mit Ultraschall, RFM69 und JeeLink
RaspberryMatic HM Zentrale | diverse HM Devices | AskSinPP Devices

Offline papa

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1231
Antw:AskSin++ Library
« Antwort #1022 am: 02 Oktober 2018, 22:17:25 »
Ja - man könnte ein Regsiter definieren, aber das wird dann immer in den Flash geschrieben. Das macht der Chip dann nicht ewig mit.
Besser wäre, eine Action zu definieren. Mal aus
$HMConfig::culHmSubTypeSets{"Values"} = { };
folgendes machen
$HMConfig::culHmSubTypeSets{"Values"} = { pct =>"[-value-] ... [-ontime-] [-ramptime-]" };
Dann müsste es möglich sein, wie beim Dimmer, ein Byte und 2 2-Byte-Werte zu übertragen. Leider wird FHEM allerdings die 2-Byte-Werte noch mit CUL_HM_encodeTime16() umrechnen.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Offline Tom Major

  • Full Member
  • ***
  • Beiträge: 200
    • TomMajor@github
Antw:AskSin++ Library
« Antwort #1023 am: 03 Oktober 2018, 00:38:39 »
Ja - man könnte ein Regsiter definieren, aber das wird dann immer in den Flash geschrieben. Das macht der Chip dann nicht ewig mit.

Guter Punkt, wobei Du wahrscheinlich EEPROM und nicht Flash meinst? Die Register sollten in den EE geschrieben werden (nehme ich zumindest an).
EE hat mindestens 100k Schreibzyklen gegenüber 10k beim Flash.
FHEM 5.x auf Raspberry Pi 3 | OWServer mit I2C/DS2482 | 1-Wire 6fach S0-Stromzähler ATtiny/DS2423 Emu. | Heizungs-Mon. mit Firmata (mighty-1284p) | Ölstand-Mon. mit Ultraschall, RFM69 und JeeLink
RaspberryMatic HM Zentrale | diverse HM Devices | AskSinPP Devices

Offline papa

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1231
Antw:AskSin++ Library
« Antwort #1024 am: 03 Oktober 2018, 20:40:03 »
Ja natürlich EEPROM
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Offline Klaus0815

  • Full Member
  • ***
  • Beiträge: 428
Antw:AskSin++ Library
« Antwort #1025 am: 04 Oktober 2018, 18:21:39 »
Hallo papa,  sorry wenn es etwas verwirrend war
Was ich bräuchte wäre quasi der Universalsensor zur Temperaturmessung, egal ob DS18B20, DHT22, BME280,...
Und dann zusätzlich ein Taster-Eingang,  dort kann ich dann z.B. einen Bewegunsmelder, einen Türkontakt, ein Taster der irgend eine Aktion auslöst anschließen


Ich hole das alte Thema noch mal hoch, habe jetzt wieder etwas mehr Zeit zum Basteln.


Hat zufällig jemand was wie oben beschrieben am laufen?
Notlösung wäre sonst einfach 2 x die Mini-Platine in einem Gehäuse, aber wohl etwas übertrieben...

Grüße

Klaus

Offline MBHG

  • Full Member
  • ***
  • Beiträge: 100
Antw:AskSin++ Library
« Antwort #1026 am: 09 Oktober 2018, 19:19:52 »
Hallo,

inzwischen habe ich einige von den Modulen am Laufen. Da ich es Leid war, immer die Kabel zu löten, habe ich mal ein Layout entworfen. Im Prinzip ist es ein 5v Pro Mini (durch Drahtbrücken könnte man auch 3.3v einsetzen), mit einem CC1101, Levelschifter und Ausgängen. Die Widerstände möchte ich unter dem Pro Mini verlöten um Platz zu sparen.

Daran anschließen kann man entweder Relais, Temperatursensoren etc....

Hat jemand Verbesserungsvorschläge?

Gruss Marc
-----------------------------------------------------------
Debian Linux, NanoCUL 868, NanoCUL 433, 3x HM-LC-SW4-BA-PCB, HM-WDS10-TH-O, HM Asksin Unisensor, RCS 1000 N Comfort, Magic Home, Rauchmelder PT2262

Offline Tom Major

  • Full Member
  • ***
  • Beiträge: 200
    • TomMajor@github
Antw:AskSin++ Library
« Antwort #1027 am: 09 Oktober 2018, 20:09:43 »
Warum nicht gleich ein 3,3V Pro Mini? Spart 6x Widerstand und bei den HM Modulen ist es in der Regel performance-mäßig egal ob 8 oder 16 MHz..
FHEM 5.x auf Raspberry Pi 3 | OWServer mit I2C/DS2482 | 1-Wire 6fach S0-Stromzähler ATtiny/DS2423 Emu. | Heizungs-Mon. mit Firmata (mighty-1284p) | Ölstand-Mon. mit Ultraschall, RFM69 und JeeLink
RaspberryMatic HM Zentrale | diverse HM Devices | AskSinPP Devices

Offline kpwg

  • Full Member
  • ***
  • Beiträge: 286
Antw:AskSin++ Library
« Antwort #1028 am: 09 Oktober 2018, 20:30:50 »
Oder das papa-Board, hervorgegangen aus dem Fensterdrehgriffkontakt in der Bastelecke: https://github.com/pa-pa/HMSensor
Sehr kleine Abmessungen, alles Wichtige an Bord, preiswert aufzubauen, 8 Pins für alles Mögliche.
Man muss halt den Kram zusammentragen und Platinen ordern sowie sehr kleine SMDs löten.
Ich hatte mir auch erst überlegt, zum frickeln und testen einen pro mini mit cc1101 aufzubauen, sehe da nur keine Vorteile.
« Letzte Änderung: 10 Oktober 2018, 06:06:39 von kpwg »
FHEM 5.x auf RasPi3, Debian Stretch, mehrere E6-Boards, CUL-HM/FS20, KS200, LGW mit LaCrosse/EC3000, reichlich HM/HB, ESPEasy, SonOff, uvm.

Offline papa

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1231
Antw:AskSin++ Library
« Antwort #1029 am: 09 Oktober 2018, 21:04:58 »
Oder eine Platine von hier https://github.com/alexreinert/PCB
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Offline MBHG

  • Full Member
  • ***
  • Beiträge: 100
Antw:AskSin++ Library
« Antwort #1030 am: 09 Oktober 2018, 21:44:29 »
Warum nicht gleich ein 3,3V Pro Mini? Spart 6x Widerstand und bei den HM Modulen ist es in der Regel performance-mäßig egal ob 8 oder 16 MHz..

Ist ein berechtigter Punkt, mit einem 3.3v modul habe ich den Unisensor aufgebaut. Der Gedanke bei 5v zu bleiben kam dadurch, dass ich in aller Regel für meine Anwendungen 5v zur Verfügung habe. Außerdem kann ich durch drei einfache Drahtbrücken auch einen 3.3v Pro Mini verwenden.
Gruss
« Letzte Änderung: 10 Oktober 2018, 07:19:06 von MBHG »
-----------------------------------------------------------
Debian Linux, NanoCUL 868, NanoCUL 433, 3x HM-LC-SW4-BA-PCB, HM-WDS10-TH-O, HM Asksin Unisensor, RCS 1000 N Comfort, Magic Home, Rauchmelder PT2262

Offline MBHG

  • Full Member
  • ***
  • Beiträge: 100
Antw:AskSin++ Library
« Antwort #1031 am: 10 Oktober 2018, 06:24:31 »
Oder eine Platine von hier https://github.com/alexreinert/PCB

Danke, diese habe ich auf einer Lochraster Platine nachgebaut und wirklich sehr gut. Sie ist mir aber zu gross und zu speziell um sie zB in meine Gegensprechanlage oder Steckdosenleiste einzubauen.
-----------------------------------------------------------
Debian Linux, NanoCUL 868, NanoCUL 433, 3x HM-LC-SW4-BA-PCB, HM-WDS10-TH-O, HM Asksin Unisensor, RCS 1000 N Comfort, Magic Home, Rauchmelder PT2262

Offline MBHG

  • Full Member
  • ***
  • Beiträge: 100
Antw:AskSin++ Library
« Antwort #1032 am: 10 Oktober 2018, 07:20:39 »
Oder das papa-Board, hervorgegangen aus dem Fensterdrehgriffkontakt in der Bastelecke: https://github.com/pa-pa/HMSensor
Sehr kleine Abmessungen, alles Wichtige an Bord, preiswert aufzubauen, 8 Pins für alles Mögliche.
Man muss halt den Kram zusammentragen und Platinen ordern sowie sehr kleine SMDs löten.
Ich hatte mir auch erst überlegt, zum frickeln und testen einen pro mini mit cc1101 aufzubauen, sehe da nur keine Vorteile.

Das klingt doch super. Muss ich mir mal ansehen. Danke
-----------------------------------------------------------
Debian Linux, NanoCUL 868, NanoCUL 433, 3x HM-LC-SW4-BA-PCB, HM-WDS10-TH-O, HM Asksin Unisensor, RCS 1000 N Comfort, Magic Home, Rauchmelder PT2262

Offline ext23

  • Hero Member
  • *****
  • Beiträge: 2746
    • Homepage
Antw:AskSin++ Library
« Antwort #1033 am: 11 Oktober 2018, 14:21:12 »
Hallo,

eine Frage, ich habe derzeit ein Schlüsselbrett an dem ich 3 1-Wire iButtons hängen kann. Das Abfragen der Buttons funktioniert aber nur mittelprächtig weil FHEM doch teilweise stark blockiert etc.
Mir kam jetzt die Idee das mit einem HB-GEN-SENS zu realisieren. Sprich der pollt den 1-Wire Bus und übermittelt an FHEM die vorhandenen gefundenen iButton Seriennummern. Bekommt man das hin? Kann ich an FHEM eine "Liste" dynamischer Länge übermittelt? Gut in meinem Fall sind es nur maximal 3 Seriennummern...

Allerdings ist das vielleicht keine gute Idee über Funk zu regeln, vielleicht doch lieber Kabelbasiert?

/Daniel
HM, FS20, 1-Wire, PanStamp, AVR-NET-IO, SIS-PM, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

Offline Tom Major

  • Full Member
  • ***
  • Beiträge: 200
    • TomMajor@github
Antw:AskSin++ Library
« Antwort #1034 am: 11 Oktober 2018, 15:44:41 »
Mir kam jetzt die Idee das mit einem HB-GEN-SENS zu realisieren. Sprich der pollt den 1-Wire Bus und übermittelt an FHEM die vorhandenen gefundenen iButton Seriennummern. Bekommt man das hin? Kann ich an FHEM eine "Liste" dynamischer Länge übermittelt? Gut in meinem Fall sind es nur maximal 3 Seriennummern...

Nach meinen Infos beträgt die max. Payload 17 Bytes. Mit 3 Seriennummern a 6 Byte also etwas knapp, aber man könnte ja die Nummern multiplexed auf mehrere Telegramme aufteilen.
Auf jeden Fall brauchst du dafür einen custom Perl script um das dann im gewünschten Format in FHEM reinzubekommen, möglich sollte es aber sein.
 
FHEM 5.x auf Raspberry Pi 3 | OWServer mit I2C/DS2482 | 1-Wire 6fach S0-Stromzähler ATtiny/DS2423 Emu. | Heizungs-Mon. mit Firmata (mighty-1284p) | Ölstand-Mon. mit Ultraschall, RFM69 und JeeLink
RaspberryMatic HM Zentrale | diverse HM Devices | AskSinPP Devices