Senden via Jeelink/LaCrosse

Begonnen von user1, 11 August 2015, 18:14:50

Vorheriges Thema - Nächstes Thema

HCS

Zitat von: user1 am 08 September 2015, 21:08:31Weshalb nicht die eingestellte Baudrate verwenden, jedenfalls wenn kein "toggle" eingestellt ist? Das scheint mir eine unnötige Einschränkung zu sein.
Weil ich auf die Idee schlicht nicht gekommen bin :D

Kann ich einbauen.

Zusätzlich (oder alternativ?) könnte ich auch ein Kommando (das man dann in die initCommands setzen kann) bereitstellen, um die data rate für das Senden festzulegen.
z.B. so: 9579c

user1

Die Sendebaudrate auswählen zu können wäre natürlich eine gute Sache.

Eine andere Frage: Ich kriege das Beispiel mit dem Modul "36_CustomSensorExample.pm" nicht zum laufen... irgendetwas klappt mit dem einbinden von des CustomSensorExample nicht.

## folgendes geht:
define XYZ LaCrosse 3C
attr XYZ IODev myJeeLink

## aber hier gibt's einen Fehler:
define myCS CustomSensorExample 0B
attr myCS IODev myJeeLink

## im log file steht dann:
2015.09.08 21:46:36 1: myCS: no I/O device

Leider blicke ich in FHEM nicht so recht durch, wie die verschiedenen Teile hier zusammenspielen...

Wzut

Zitat von: user1 am 08 September 2015, 21:51:54
## aber hier gibt's einen Fehler:
define myCS CustomSensorExample 0B

Ahh ja ... und wir dürfen/sollen nun raten wie der Fehler aussieht und was man dagegen tun kann ?
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

user1

Also nochmals eine detailliertere Zusammenfassung:

Ich versuche, 36_CustomSensorExample.pm zu verwenden. Eine Node sendet Daten, welche der JeeLink auch empfängt (ich sehe "OK CC ...", wenn ich direkt über ttyUSBx connecte und den Output des JeeLinks anschaue).

Mir gelingt es nun aber nicht, diese Meldung in FHEM zu verwenden. Im config-File habe ich besagte Zeilen:


define myCS CustomSensorExample 0B
attr myCS IODev myJeeLink


Im Log-File erhalte ich aber


(...)
1: myCS: no I/O device
(...)
3: myJeeLink: Unknown code OK CC 11 119 , help me!


Meiner Vermutung ist nun, dass die Message nicht korrekt dispatched wird, und deshalb nicht in CustomSensorExample landet, weil dieser eben nicht mit dem JeeLink assoziert ist.

Über "attr IODev" (wie das bei z.B. LaCrosse klappt) funktioniert das nicht, siehe oben.

Frage: Was mache ich hier falsch, bzw. wie komme ich zum Ziel?

Danke für Input.

user1

Funktioniert jetzt alles mit zusätzlich gesetzter MatchList, von daher erledigt.

Seltsam sind die Logeinträge beim Starten aber trotzdem, auch wenn sie keine Konsequenz haben:


1: myCS: no I/O device
(...)
3: No I/O device found for myCS


HCS

Zitat von: user1 am 09 September 2015, 10:40:19Seltsam sind die Logeinträge beim Starten aber trotzdem, auch wenn sie keine Konsequenz haben
Keine Ahnung wo es bei Dir klemmt.
Hast Du in der fhem.cfg den "define myCS ..." evtl. von Hand vor den "define myJeeLink ..." gepackt?

Bei mir sieht das so aus:
2015.09.09 11:29:17 1: Including fhem.cfg
2015.09.09 11:29:17 3: telnetPort: port 7072 opened
.
.
2015.09.09 11:29:18 3: Opening myJeeLink device /dev/ttyUSB0
2015.09.09 11:29:18 3: Setting myJeeLink serial parameters to 57600,8,N,1
2015.09.09 11:29:18 3: myJeeLink device opened
.
.
2015.09.09 11:29:22 3: NodeSensors: I/O device is myJeeLink
2015.09.09 11:29:23 3: myCS: I/O device is myJeeLink
.
.



Zitat von: user1 am 09 September 2015, 10:40:19
Funktioniert jetzt alles mit zusätzlich gesetzter MatchList, von daher erledigt.

Hatte ich doch geschrieben:
Zitat von: HCS am 15 August 2015, 20:38:20
...
Beim JeeLink sind die Attribute Clients und MatchList zu beachten, die gesetzt werden müssen, um den CustomSensor zu definieren.
...


user1

Wegen der fehlenden MatchList: war mein Fehler, hatte ich übersehen.

Was den log-Eintrag angeht: Die Meldung war weil ich auch den Clients-Eintrag nicht richtig gesetzt hatte :-( war wohl etwas spät...

Die LaCrosse-Jeelink Firmware habe ich unterdessen an meine Zwecke angepasst. Dabei sind mir zwei Dinge aufgefallen

- RFMxx::ClearFifo() ist als bool deklariert, liefert aber keinen Wert zurück. Hat keine Bedeutung, aber der Compiler warnt:


bool RFMxx::ClearFifo() {
  if (IsRF69) {
    WriteReg(REG_IRQFLAGS2, 16);
  }
  else {
    for (byte i = 0; i < PAYLOADSIZE; i++) {
      spi16(0xB000);
    }
  }
}


- In CustomSensor::SendFrame wird rfm 'by value' übergeben, und nicht als Pointer oder Referenz, was mir eigenartig erscheint:


void CustomSensor::SendFrame(struct CustomSensor::Frame *frame, RFMxx rfm) { ... }



Zur Frage, was das Ganze am Ende gibt:

Ein Mikrokontroller wird bei meiner Heizung Funktionen umschalten (via Relais). Gleichzeitig überwacht er Temperatur und Feuchtigkeit im Keller und kann Lüftung bzw. Entfeuchter anwerfen. Da diese Funktionen wichtig sind, habe ich einen Rückkanal implementiert. Die gesamte Kommunikation läuft über LaCrosse-5-Byte Frames, da ich bereits ein paar TechnoLine-Sensoren im Einsatz habe und einen Protokoll-Zoo vermeiden möchte. Drei Bytes Nutzdaten reichen mir allemal. Statt der '9' im ersten Nibble sind jetzt auch je ein Werte für Custom Frames und für Rückkanal vorgesehen (das Acknowedge geht so, dass der Empfänger bei Erhalt das erste Nibble abändert, die CRC neu berechnet, und das Frame direkt wieder zurücksendet).

Die Behandlung des Rückkanals findet vollständig im Jeelink statt (in einer Funktion, die von loop() aus aufgerufen wird). Diese sendet die Frames wiederholt in definierbaren Intervallen, bis ein Acknowledge vom Empfänger kommt (z.B. alle 100ms, z.B. max 10 Mal). Die ACK-Meldung wird an FHEM durchgereicht, bzw. ein NAK wenn keines eintrifft. Damit lassen sich auch Nodes sicher "aufwecken", welche im stromsparenden Listen-Modus des RFM69 warten; der Preis dafür ist dann eine gewisse Latenz.

Danke für das Beipiel mit dem CustomSensor, und die diversen Posts.

HCS

Zitat von: user1 am 12 September 2015, 22:54:35
- RFMxx::ClearFifo() ist als bool deklariert, liefert aber keinen Wert zurück. Hat keine Bedeutung, aber der Compiler warnt:
Habe es für die kommende Version geändert. Seltsam, dass ich da keine Compiler Warnung sehe.

Zitat von: user1 am 12 September 2015, 22:54:35
- In CustomSensor::SendFrame wird rfm 'by value' übergeben, und nicht als Pointer oder Referenz, was mir eigenartig erscheint:
Im Prinzip ist es egal, an der RFM Instanz wird ja in der SendFrame nichts geändert. Habe es aber geändert, dann spart es etwas Arbeitsspeicher.

Zitat von: user1 am 12 September 2015, 22:54:35
Ein Mikrokontroller wird bei meiner Heizung Funktionen umschalten (via Relais). Gleichzeitig überwacht er Temperatur und Feuchtigkeit im Keller und kann Lüftung bzw. Entfeuchter anwerfen ...
Off Topic:
Etwas ganz ähnliches habe ich hier auch laufen, allerdings auf einer völlig anderen Basis:
Die Steuerung der Heizung läuft im Heizungskeller auf einem Android-Tablet als Android-App, das per IOIO (https://www.sparkfun.com/products/12633) über Relais zum Steuern der Heizung, Optokopplern für die Eingänge um Ist-Zustände zu haben, Temperatursensoren usw. mit der Heizung und dem Rest im Keller kommuniziert. Diese Steuerung läuft völlig Autark. Vorteil: Das Tablet als Steuerung hat sozusagen Display, USV, WiFi usw. schon integriert und braucht kein FHEM, um die Heizung sinnvoll weiter zu fahren. Es stellt einen REST Web Service zur Verfügung, über den FHEM sich die aktuellen Werte abholt und Soll-Vorgaben setzen kann.

Wie das in FHEM mit SmartVisu als Frontend aussieht, kann man hier sehen (http://fhem.de/SmartVisu.png), in den Blöcken mit dem Titel "Heizung"

HCS

Zitat von: user1 am 08 September 2015, 21:51:54
Die Sendebaudrate auswählen zu können wäre natürlich eine gute Sache.
Die gute Sache wurde impementiert.
Siehe hier: http://forum.fhem.de/index.php/topic,14786.msg340076.html#msg340076

DokHasenbein

Hallo,

Entschuldigung, dass ich dieses Thema wieder neu anfasse. Ich versuche mich gerade an einem kleinen Bastelprojekt zum etablieren einer FHEM zu IR Funkstrecke (um meine alte Stereoanlage steuern zu können). Ich habe das Beispielprojekt erfolgreich nachgebaut, allerdings nur mit der 10.1o Firmware auf dem Jeelink-Nachbau. Mit der aktuellen 10.1q funktioniert es nicht mehr.
Es werden zwar die periodischen Sendungen vom CustomSensorExample empfangen, das Senden scheint aber nicht richtig zu funktionieren, denn es kommt keine Antwort vom CustomSensorExample.

HCS

Zitat von: DokHasenbein am 04 März 2017, 15:48:23
Mit der aktuellen 10.1q funktioniert es nicht mehr.
Es werden zwar die periodischen Sendungen vom CustomSensorExample empfangen, das Senden scheint aber nicht richtig zu funktionieren, denn es kommt keine Antwort vom CustomSensorExample.
Ich schaue mal, warum das so sein könnte.
Verwendest Du RFM12 oder RFM69?

DokHasenbein

Vielen Dank. Ich verwende einen RFM12.

HCS

Ich kann das Problem nicht nachvollziehen.
Habe auf einen JeeLink die 10.1q geflasht
[LaCrosseITPlusReader.10.1q (RFM69 f:868300 r:17241)]
und auf den Anderen das original CustomSensorExample.

wenn ich ein
11,4,5s
sende, kommt ein
OK CC 11 1 9
zurück.

OK, hat sich überschnitten. Dann probiere ich es mal anders herum.
Also mit dem JeeLink-Sketch auf dem RFM12 und demCustomSensorExample auf dem RFM69 (habe nur einen mit RFM12)

HCS

Zitat von: DokHasenbein am 05 März 2017, 20:50:27
Ich verwende einen RFM12.
So rum kann ich es anchvollziehen. Die Senderei auf dem RFM12 geht wohl nicht mehr.
Ich schaue mal, ob man es reparieren kann.

Hast ja aber aktuell zwei Optionen:
- 10.1o nehmen
- RFM69 nehmen

DokHasenbein

Bin erstmal beruhigt, dass der Fehler nicht bei mir liegt (was ich natürlich erst nach einigen Tagen rumprobieren rausgekriegt habe). Ich habe jetzt die 10.1o in Betrieb. Hat das irgendwelche gravierenden Nachteile? Ich benutze sonst nur LaCrosse-TempHum-Sensoren und jetzt eben den IR-Sender-Prototypen damit.