HB-1W-KEY auf PanStamp mit AskSin

Begonnen von Prof. Dr. Peter Henning, 18 April 2014, 14:36:24

Vorheriges Thema - Nächstes Thema

Prof. Dr. Peter Henning

Status Update:

- neuer Codeblock für das Modul CUL_HM definiert, der HB-1W-KEY Messages auswertet.
- Codeergänzungen für das Hilfsfile HMConfig.pm definiert.
- Arduino-Sketch HB-1W-KEY kommuniziert schon ganz gut mit diesem Modul

Es erweist sich als ziemlich kompliziert, die Abläufe in der Asksin-Library aufzuschlüsseln...

@Tobias: Das ist eine andere Herangehensweise. Ich definiere nicht 1-Wire Devices in FHEM - sondern ein neuartiges HomeMatic-Device, eben HB-1W-KEY. Die 1-Wire-Devices auf dem Bus sind nur diesem Gerät bekannt - denn es soll ja, weil sicherheitskritisch, unabhängig von FHEM arbeiten können.

LG

pah

Tobias

Hallo pah,
ist es dann nicht besser dem Firmata Sketch eine Funkkomponente zu können?
So wie Firmata jetzt interagiert finde ich es schon Klasse! Funktioniert per USB und Ethernet. Jetzt müsste nur noch Funk dazukommen. Ob nun per RFM12B oder CC1101 über Panstamp/JeeLink oder CUL ist eigentlich egal...

Sonst müsste ja für jedes 1wireDevice ein eigenes HB-Device kreiirt werden.....:(
Maintainer: Text2Speech, TrashCal, MediaList

Meine Projekte: https://github.com/tobiasfaust
* PumpControl v2: allround Bewässerungssteuerung mit ESP und FHEM
* Ein Modbus RS485 zu MQTT Gateway für SolarWechselrichter

Prof. Dr. Peter Henning

Oh, das kann man natürlich machen.

Aber da ich meine Zeit sehr stark einteilen muss, werde ich es sicher nicht tun.

LG

pah

Tobias

Zitat von: ntruchsess am 12 Mai 2014, 10:24:34
So ganz egal ist das nicht. Die genannten Funkmodule arbeiten in den ISM-Bändern, in denen man nicht völlig frei funken, sondern pro Gerät maximal 1% der Zeit aktiv sein darf. Das schränkt die Echtzeittauglichkeit, wie Du sie von Firmata gewohnt bist, deutlich ein. Ich habe letztes Jahr Firmata über 'PanStream' implementiert, hat prinzipiell funktioniert, der PanStream müsste aber noch deutlich optimiert werden - das implementierte Handshaking mit Acknowledge-packeten ähnlich TCP ist wg. der Latenz recht ineffektiv und kostet zu viel Bandbreite was (wegen der 1%-regel) die Verbindung ziemlich ausbremst

Ok, mir persönlich ist es egal... aber vieleicht ist auch WLAN eine Alternative? Es gibt ja diese netten WLAN FunkModule die 1-3 serielle Schnittstellen zur Verfügung stellen
Maintainer: Text2Speech, TrashCal, MediaList

Meine Projekte: https://github.com/tobiasfaust
* PumpControl v2: allround Bewässerungssteuerung mit ESP und FHEM
* Ein Modbus RS485 zu MQTT Gateway für SolarWechselrichter

Dirk

Zitat von: ntruchsess am 12 Mai 2014, 10:24:34
Die genannten Funkmodule arbeiten in den ISM-Bändern, in denen man nicht völlig frei funken, sondern pro Gerät maximal 1% der Zeit aktiv sein darf.
Das wiederum stimmt so auch nicht.
Das Gerät darf natürlich immer aktiv sein. Nur alle gesendeten Nachrichten dürfen nicht mehr Zeit als 36s pro Stunde verbrauchen (1%-Regelung)

ZitatDas schränkt die Echtzeittauglichkeit, wie Du sie von Firmata gewohnt bist, deutlich ein.
Auch nur bedingt. Wenn man Sensoren / Schalter usw. einsetzt, können diese Ereignisse natürlich in Echtzeit senden.
Und wenn man bedenkt das normale Messages nur wenige Millisekunden benötigen, dann kann man mit 36s Zeit in einer Stunde schon rech viele Nachrichten verschicken
"Dauersender" sind hier natürlich ausgenommen. Aber wer möchte schon mit ständig sendenden Geräten sein Funkband "zumüllen".

Gruß
Dirk

Tobias

Zitat von: ntruchsess am 12 Mai 2014, 11:03:10
WLAN wäre prima geeignet. Mit so einem WLAN<->Seriell Modul ist das mehr eine Hardwarebastelei (der Sketch sieht ja nur eine Serielle Schnittstelle, das Modul müsste man als TCP-Client im Modus 'RAW' konfigurieren - Gegenstelle wäre die IP-Addresse/Port des FRM-moduls), mit einem Wifi-shield müsste man noch ein bischen war am Sketch machen.
Die ENC28J60 Module arbeiten aber nicht per RX/TX sondern per SPI
Aber die Diskussion ist wohl wieder besser hier aufgehoben ;)
Maintainer: Text2Speech, TrashCal, MediaList

Meine Projekte: https://github.com/tobiasfaust
* PumpControl v2: allround Bewässerungssteuerung mit ESP und FHEM
* Ein Modbus RS485 zu MQTT Gateway für SolarWechselrichter

Dirk

Zitat von: ntruchsess am 12 Mai 2014, 17:04:26
Funktioniert garantiert nicht befriedigend (und legal), wenn man versucht darüber 20 1-Wire-sensoren im 5 Sekunden-takt zu pollen.
Pollen finde ich grundsätzlich nicht schön.
Daher könnte der AVR den 1Wire Master spielen lassen. Dieser pollt dann die angeschlossenen Sensoren.

Bei Änderungen kann dieser Events über Funkt (AskSin, SWAP, was auch immer) wegschicken.
Die Schwellwerte muss man natürlich entsprechend konfigurieren.

Gruß
Dirk

Dirk

Zitat von: ntruchsess am 12 Mai 2014, 17:57:20
Im Kontext des Firmata-protokolls (und ausschließlich darauf bezog sich meine Aussage) ist der AVR per Definition nicht der Master. Und genau deshalb ist das Firmata-protokoll nicht besonders gut für die Anbindung über ISM-Band-funkfrequenzen geeignet.
Ja, das hab ich daraus entnommen.
Das war lediglich ein Vorschlag wie das ganze ohne Polling Over The Air auskommen würde.

ntruchsess

... nicht dass sich wer wundert. Ich hab meine Offtopic-Beiträge zur Firmata gerade alle entsorgt.
while (!asleep()) {sheep++};

oli82

Wie ist eigentlich der Stand der Dinge hier?
Suche eine Möglichkeit, meine iButtons per Funk an zu binden und würde am liebsten bei 868Mhz bleiben