Signalduino Entwicklung

[Sidey]

Kannst Du im Logfile was erkennen und mal zusenden?

[Hasbro]

Bis sich FHEM aufhäng sehe folgendes, beim drücken der Fernbedienung. (siehe Anhang)

Habe auch noch Warnungen beim Start von FHEM in der Konsole.

Die bei einem erneutem start dann aber weg sind.

pi@pi ~ $ sudo /etc/init.d/fhem start
Starting fhem...
pi@pi ~ $ Undefined subroutine &main::round called at ./FHEM/00_SIGNALduino.pm line 1404.

[hjgode]

Bis sich FHEM aufhäng sehe folgendes, beim drücken der Fernbedienung. (siehe Anhang)

Habe auch noch Warnungen beim Start von FHEM in der Konsole.

Die bei einem erneutem start dann aber weg sind.

pi@pi ~ $ sudo /etc/init.d/fhem start
Starting fhem...
pi@pi ~ $ Undefined subroutine &main::round called at ./FHEM/00_SIGNALduino.pm line 1404.

Undefined subroutine &main::round called at ./FHEM/00_SIGNALduino.pm line 1404.

hatte ich gestern auch, war aber nach fhem "update" weg. Gestartet bin ich mit der fhem-5.6.deb und dann erst "update forece signalDuino" gemacht und da war der Fehler da. Dann ein update des fhem systems und der Fehler ware weg.

~josef

[Sidey]

Ich verwende die Round Funktion aus FHEM.

Ich werde mal recherchieren, ab welcher Revision die Funktion verfügbar ist..

Danke für diesen Hinweis!

Grüße Sidey

[Hasbro]

@josef
Danke für den Tip. Update des FHEM Systems hat es gebracht, obwohl ich es erst ganz frisch aufgesetz habe.

Keine Fehlermeldungen mehr und FHEM stürzt auch nicht mehr ab.

Frank

[pejonp]

Ich verwende die Round Funktion aus FHEM.
...

Hallo,
mit    perl -MCPAN -e 'install Math::Round'   kann man bei Bedarf, hier die Round-Funktion, unter Linux nachinstallieren. Vielleicht hilft es ja.
Jörg

[Sidey]

Hallo,
mit    perl -MCPAN -e 'install Math::Round'   kann man bei Bedarf, hier die Round-Funktion, unter Linux nachinstallieren. Vielleicht hilft es ja.
Jörg

Nein, das hilft an der Stelle leider nicht.
Da ich die Round Funktion aus der Lib nicht eingebunden habe. Das führt leider zu Komplikationen, da ja bereits eine round Funktion in FHEM integriert ist.

Ich würde in die Doku erst mal aufnehmen, ab welcher Revision das Modul funktioniert.
Man kann in Perl auch zur Laufzeit feststellen, ob eine bestimmte Funktion existiert.
Da muss ich mich aber erst mal schlau machen.
Ein update von FHEM will ich aber auf keinen Fall von meinem Modul heraus triggern.


Nachtrag:
Es wird nun beim initialisieren auf die Funktion round geprüft
Und im Wiki habe ich einen Hinweis darauf ergänzt. http://www.fhemwiki.de/wiki/SIGNALDuino
Grüße Sidey

[Sidey]

ich habe den signalDuino nun auch mal nachgebaut und mit verbose=5 empfängt er auch fleißig Daten (Anhang fhem-2015-08.log). Was fange ich nun damit an?

Bei mir senden, soweit ich weiß, Temperatur/Feuchte Sensoren von TFA, EC3000 Strom-Messer, EnergieSparAmpel  ESA 2000, ELV Funkthermometer, Elro AB440 Funksteckdosenschalter.

Gut, was für einen Empfänger hast Du am SIGNALduino? Einen für 433 Mhz oder 868?

In dem Log, konnte ich jetzt leider nicht direkt deine Sensoren zuordnen. Kannst Du eventuell erkennen, wann welcher Sensor etwas überträgt und das im Logfile zuordnen? Von TFA gibt es unter anderem auch viele verschiedene Sensoren und Protokolle. Welcher ist es genau?

Grüße Sidey

[hjgode]

Hallo Sidey

ich habe die TFA Dostmann Pure Plus (KatNr 35.1107) zzgl. zwei weiteren Sensoren ((Kat.Nr. 30.3127).

Die Dinger empfange ich alle mit einemCode auf einem NetDuino und 'post' die Daten via HTTP in mein FHEM. Diesen NetDuino möchte ich aber entfernen.

Der signalDuino läuft mit nem 433MHz Modul. An meinem Haupt Fhem-System hängen: ein JeeLink, ein NanoCul433, ein NanoCul868 und ein fhemDuino.

Für den Test habe ich einen zweiten Fhem unter Debian 8 installiert und nur den SiganDuino angehängt.

Ich habe die Signale mal mit dem was ich bzgl der Sensoren kenne verglichen. Die AE5E Werte werden vom signalDuino 'gelesen', die 7547 Werte kenne ich von RemoteReceiver. Wenn man zufällige Werte voneinander abzieht, kann man ein Muster erkennen:

AE5E174A4E17E8ED141E1200-7547CE9E69C168F3245C0000
01 03 00 21 18 15 18 04 18 21 14 21 02 02 20 16 15 15 09 20 14 20
=================

AE5E174A2E17E8ED141D2600-7547CEDE68C168F365620000
01 03 00 21 18 15 09 12 16 12 18 06 12 03 02 16 19 13 04 07 05 06
=================

Der bisherige Decoder sieht so aus:

Code Auswählen Erweitern

/*
* RemoteSensor v1.0.1 (20120213)
*
* This library encodes, encrypts en transmits data to
* remote weather stations made by Hideki Electronics..
*
* Copyright 2011 by Randy Simons http://randysimons.nl/
*
* Parts of this code based on Oopsje's CrestaProtocol.pdf, for which
* I thank him very much!
*
* License: GPLv3. See license.txt
*/

#include <SensorReceiver.h>

byte SensorReceiver::halfBit = 0;
word SensorReceiver::clockTime;
boolean SensorReceiver::isOne;
unsigned long SensorReceiver::lastChange=0;
SensorReceiverCallback SensorReceiver::callback;
byte SensorReceiver::data[14];
byte SensorReceiver::packageLength;
word SensorReceiver::duration;
boolean SensorReceiver::enabled;

void SensorReceiver::init(short int interrupt, SensorReceiverCallback callbackIn) {
  callback = callbackIn;
 
  enable();
 
  if (interrupt >= 0) {
attachInterrupt(interrupt, interruptHandler, CHANGE);
  } 
}

void SensorReceiver::setCallback(SensorReceiverCallback callbackIn){
  callback = callbackIn;
}

void SensorReceiver::interruptHandler() {
if (!enabled) {
return;
}

/* I'll follow CrestaProtocol documentation here. However, I suspect it is inaccurate at some points:
* - there is no stop-bit after every byte. Instead, there's a start-bit (0) before every byte.
* - Conversely, there is no start-bit "1" before every byte.
* - An up-flank is 0, down-flank is 1, at least with both my receivers.
*
* However, since the first start-bit 0 is hard to distinguish given the current clock-detecting
* algorithm, I pretend there *is* a stop-bit 0 instead of start-bit. However, this means the
* last stop-bit of a package must be ignored, as it simply isn't there.
*
* This manchester decoder is based on the principle that short edges indicate the current bit is the
* same as previous bit, and that long edge indicate that the current bit is the complement of the
* previous bit.
*/

static byte halfBitCounter = 255;
unsigned long currentTime=micros();
duration=currentTime-lastChange; // Duration = Time between edges

lastChange=currentTime;

if (halfBit==0) {
// Automatic clock detection. One clock-period is half the duration of the first edge.
clockTime = duration >> 1;

// Some sanity checking, very short (<200us) or very long (>1000us) signals are ignored.
if (clockTime < 200 || clockTime > 1000) {
return;
}
isOne = true;
}
else {
// Edge is not too long, nor too short?
if (duration < (clockTime >> 1) || duration > (clockTime << 1) + clockTime) { // read as: duration < 0.5 * clockTime || duration > 3 * clockTime
// Fail. Abort.
reset();
return;
}

// Only process every second half bit, i.e. every whole bit.
if (halfBit & 1) { 
byte currentByte = halfBit / 18;
byte currentBit = (halfBit >> 1) % 9; // nine bits in a byte.

if (currentBit < 8) {
if (isOne) {
// Set current bit of current byte
data[currentByte] |= 1 << currentBit;
}
else {
  // Reset current bit of current byte
  data[currentByte] &= ~(1 << currentBit);
}
}
else {
// Ninth bit must be 0
if (isOne) {
// Bit is 1. Fail. Abort.
reset();
return;
}                   
}

if (halfBit == 17) { // First byte has been received
// First data byte must be x75.
if (data[0] != 0x75) {
reset();
return;
}
}
else if (halfBit == 53) { // Third byte has been received
// Obtain the length of the data
byte decodedByte = data[2]^(data[2]<<1);
packageLength = (decodedByte >> 1) & 0x1f;

// Do some checking to see if we should proceed
if (packageLength < 6 || packageLength > 11) {
reset();
return;
}

halfBitCounter = (packageLength + 3) * 9 * 2 - 2 - 1; // 9 bits per byte, 2 edges per bit, minus last stop-bit (see comment above)
}

// Done?
if (halfBit >= halfBitCounter) {
if (halfBit == halfBitCounter) {
// Yes! Decrypt and call the callback
if (decryptAndCheck()) {
(callback)(data);
}
}

// reset
halfBit = 0;
return;
}
}

// Edge is long?
if (duration > clockTime + (clockTime >> 1)) { // read as: duration > 1.5 * clockTime
// Long edge.
isOne = !isOne;
// Long edge takes 2 halfbits
halfBit++;
}
}

halfBit++;
return;
}

void SensorReceiver::reset() {
halfBit = 1;
clockTime = duration >> 1;
isOne = true;
}

boolean SensorReceiver::decryptAndCheck() {
byte cs1,cs2,i;

cs1=0;
cs2=0;
for (i=1; i<packageLength+2; i++) {
cs1^=data[i];
cs2 = secondCheck(data[i]^cs2);
data[i] ^= data[i] << 1;
}

if (cs1) {
return false;
}

if (cs2 != data[packageLength+2]) {
return false;
}
return true;
}

byte SensorReceiver::secondCheck(byte b) {
  byte c;
 
if (b&0x80)
b^=0x95;
c = b^(b>>1);
if (b&1)
c^=0x5f;
if (c&1)
b^=0x5f;
   
  return b^(c>>1);
}

void SensorReceiver::enable() {
halfBit = 0;
enabled = true;
}

void SensorReceiver::disable() {
enabled = false;
}

void SensorReceiver::decodeThermoHygro(byte *data, byte &channel, byte &randomId, int &temp, short int &humidity) {
channel = data[1] >> 5;

// Internally channel 4 is used for the other sensor types (rain, uv, anemo).
// Therefore, if channel is decoded 5 or 6, the real value set on the device itself is 4 resp 5.
if (channel >= 5) {
channel--;
}

randomId = data[1] & 0x1f;

temp = 100 * (data[5] & 0x0f) + 10 * (data[4] >> 4) + (data[4] & 0x0f);
// temp is negative?
if (!(data[5] & 0x80)) {
temp = -temp;
}

humidity = 10 * (data[6] >> 4) + (data[6] & 0x0f);
}

Hilft das?

~Josef

[pejonp]

Hallo Sidey

ich habe die TFA Dostmann Pure Plus (KatNr 35.1107) zzgl. zwei weiteren Sensoren ((Kat.Nr. 30.3127).

...............

Hallo Sidey,

ich habe den 2x Bresser Art.-No. 70-09993 433MHz 5 Kanäle, dieser scheint das gleiche Protokoll wie der TFA Dostman zu haben. Ich hänge einmal ein Log an, viellicht kannst du da ja was erkennen. Mit einem andern Sketch kann ich schon Daten empfangen (http://forum.fhem.de/index.php/topic,17196.msg226073.html#msg226073).

Tschüß Jörg

[Sidey]

Hallo Josef,

ja das hilft. Das Manchester Signal, was im Log als MC auftaucht, ist dass deiner TFA Sensoren.

Weisst Du ob es schon ein Modul in Fhem gibt, welches den TFA Sensor interpretiert, oder würdest dir zutrauen da was zu entwickeln?

Grob formuliert, ist ist eine Fleiß Arbeit. Ich würde im Signalduino das Cresta Protokoll erkennen. Dazu würde ich nach 0x75 suchen, und ab da  beginnend die Daten an ein anderes Modul übergeben.

Das Modul müsste im Prinzip die Funktion encodeThermoHygro realisieren und jedes 9 Bit ignorieren oder einfach verwerfen.

Grüße Sidey

[Sidey]

Hi Jörg,

da haben sich unsere Posts ja überschnitten.
Vom Prinzip müsste man den verlinkten Code aus dem Post ja "nur" noch in ein Modul. Z.B. 14_Cresta.pm packen und die Daten vom Signalduino dort hin übergeben.

Grüße Sidey

[pejonp]

Hi Jörg,

da haben sich unsere Posts ja überschnitten.
Vom Prinzip müsste man den verlinkten Code aus dem Post ja "nur" noch in ein Modul. Z.B. 14_Cresta.pm packen und die Daten vom Signalduino dort hin übergeben.

Grüße Sidey

Hallo Sidey,

könnte diese nicht auch im 10_CUL_TCM97001.pm mit aufgenommen werden, z.b. als Cresta. Ist vielleicht nicht so viel Aufwand.
Ich habe noch kein Modul programmiert, es wird deshalb etwas dauern. Kann ich ein Modul als Grundlage nehmen ? Dann ist es vielleicht etwas einfacher.

Jörg

[Sidey]

Also Cresta hat mit tcm97001 nichts zu tun. Nimm lieber ein neues. Ich kann die ein Grundgerüst liefern wenn dir das hilft

[pejonp]

Also Cresta hat mit tcm97001 nichts zu tun. Nimm lieber ein neues. Ich kann die ein Grundgerüst liefern wenn dir das hilft

Hallo Sidey,

ich habe gedacht der signalduino benutzt auch das tcm97001 oder bringe ich da etwas durcheinander. Wenn du mir eine Grundgerüst liefern könntest, ist der Anfang vielleicht nicht ganz so schwer. Vielen Dank.

Jörg