AskSin++ Library

Begonnen von papa, 08 September 2016, 11:11:25

Vorheriges Thema - Nächstes Thema

papa

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

Tom Major

@papa
Könnte er nicht einfach im culHmRegDefine des FHEM Scripts die message length einer 'custom' message auf 4 Bytes setzen
s=>4.0
und dann im Arduino Sketch bei DEFREGISTER die 4 Bytes definieren und zum 32bit Wert zusammensetzen?
Hacky, aber danach wurde gefragt  ;)
Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker

papa

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

Tom Major

Zitat von: papa 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.

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.
Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker

papa

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

Klaus0815

Zitat von: Klaus0815 am 17 August 2018, 18:41:43
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

MBHG

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
-----------------------------------------------------------
https://smarthome.family.blog Debian Linux, NanoCUL 868, Signalduino, 4x HM-SW4, 11x HM Asksin Unisensor, NodeMCU ESP8266, RCS 1000 N Comfort, Magic Home, Rauchmelder PT2262, Babble

Tom Major

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..
Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker

kpwg

#1028
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.

papa

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

MBHG

#1030
Zitat von: Tom Major 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..

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
-----------------------------------------------------------
https://smarthome.family.blog Debian Linux, NanoCUL 868, Signalduino, 4x HM-SW4, 11x HM Asksin Unisensor, NodeMCU ESP8266, RCS 1000 N Comfort, Magic Home, Rauchmelder PT2262, Babble

MBHG

Zitat von: papa am 09 Oktober 2018, 21:04:58
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.
-----------------------------------------------------------
https://smarthome.family.blog Debian Linux, NanoCUL 868, Signalduino, 4x HM-SW4, 11x HM Asksin Unisensor, NodeMCU ESP8266, RCS 1000 N Comfort, Magic Home, Rauchmelder PT2262, Babble

MBHG

Zitat von: kpwg 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.

Das klingt doch super. Muss ich mir mal ansehen. Danke
-----------------------------------------------------------
https://smarthome.family.blog Debian Linux, NanoCUL 868, Signalduino, 4x HM-SW4, 11x HM Asksin Unisensor, NodeMCU ESP8266, RCS 1000 N Comfort, Magic Home, Rauchmelder PT2262, Babble

ext23

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, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

Tom Major

Zitat von: ext23 am 11 Oktober 2018, 14:21:12
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.
Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker