Signalduino Entwicklung

[Sidey]

Sodele,

ich habe die Fehler korrigiert.

Grüße Sidey

[Hauswart]

Ich habe scheinbar ein blödes Rechteproblem... FHEM scheint nicht auf /dev/serial/tty Zugreifen zu dürfen:
avrdude: ser_open(): can't open device "/dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0": Permission denied


Manuell mit sudo ging es problemlos, leider ist der State immer noch disconnected.


(Verwende Debian)

[Sidey]

Hi,

mach doch mal ein ls -l auf das Device, dann siehst Du ja wie die Rechte gesetzt sind.

Sidey

[Ralf9]

ich habe die Fehler korrigiert.

Danke, jetzt funktionierts.
Im Modul 14_SIGNALduino_ID7 sind aber keine Daten mehr angekommen. Es lag daran:

Code Auswählen Erweitern

- length_max      => '40',
+ length_max      => '37',
mit length_max      => '40' funktioniert es wieder.


Mir ist nicht klar was dies bewirken soll

Code Auswählen Erweitern

# Parse only if message is different within 2 seconds
SIGNALduno_Dispatch();
Es kommen trotzdem mehrere messages pro Sekunde

Code Auswählen Erweitern


2015.09.22 18:50:39 3: EAS800z converted to bits: 01001110 1 001 000011010100 1111 01000110
2015.09.22 18:50:39 3: EAS800z decoded protocolid: 7 sensor id=4E, channel=2, temp=21.2, hum=70, bat=ok
2015.09.22 18:50:39 3: EAS800z converted to bits: 01001110 1 001 000011010100 1111 01000110
2015.09.22 18:50:39 3: EAS800z decoded protocolid: 7 sensor id=4E, channel=2, temp=21.2, hum=70, bat=ok
2015.09.22 18:50:40 3: EAS800z converted to bits: 01001110 1 001 000011010100 1111 01000110
2015.09.22 18:50:40 3: EAS800z decoded protocolid: 7 sensor id=4E, channel=2, temp=21.2, hum=70, bat=ok
2015.09.22 18:51:46 3: EAS800z converted to bits: 01001110 1 001 000011010101 1111 01000101
2015.09.22 18:51:46 3: EAS800z decoded protocolid: 7 sensor id=4E, channel=2, temp=21.3, hum=69, bat=ok
2015.09.22 18:51:47 3: EAS800z converted to bits: 01001110 1 001 000011010101 1111 01000101
2015.09.22 18:51:47 3: EAS800z decoded protocolid: 7 sensor id=4E, channel=2, temp=21.3, hum=69, bat=ok
2015.09.22 18:51:47 3: EAS800z converted to bits: 01001110 1 001 000011010101 1111 01000101
2015.09.22 18:51:47 3: EAS800z decoded protocolid: 7 sensor id=4E, channel=2, temp=21.3, hum=69, bat=ok
2015.09.22 18:52:53 3: EAS800z converted to bits: 01001110 1 001 000011010101 1111 01000101
2015.09.22 18:52:53 3: EAS800z decoded protocolid: 7 sensor id=4E, channel=2, temp=21.3, hum=69, bat=ok
2015.09.22 18:52:54 3: EAS800z converted to bits: 01001110 1 001 000011010101 1111 01000101
2015.09.22 18:52:54 3: EAS800z decoded protocolid: 7 sensor id=4E, channel=2, temp=21.3, hum=69, bat=ok

Gruß Ralf

[Sidey]

Hi Ralf,

Danke, jetzt funktionierts.
Im Modul 14_SIGNALduino_ID7 sind aber keine Daten mehr angekommen. Es lag daran:

Code Auswählen Erweitern

- length_max      => '40',
+ length_max      => '37',
mit length_max      => '40' funktioniert es wieder.

Problem erkannt. Ich hab dazu mal ein Issue geöffnet. Problem ist, dass ich die Länge 2x prüfe. Einmal vor dem Demodulieren und dann noch einmal nach dem ich es demoduliert und auch Längenseitig angepasst habe.
Die Anpassung war für irgend ein Modul notwendig (erinnere mich leider nicht mehr welches), es wollte immer volle Bytes. Also fülle ich jedes Signal mit 0 Bits auf, damit alle bytes voll sind. Da ich alles hexadezimal weitergebe würde das Auffüllen auch auf nibbles reichen.
Ich hab da schon eine Idee, wie ich das lösen könnte.

Code Auswählen Erweitern

# Parse only if message is different within 2 seconds
SIGNALduno_Dispatch();

Auch dazu habe ich ein issue geöffnet. Es ist ein Bug, sowohl im code als auch im Kommentar. Genau genommen, sollte der code wie er gedacht war, alles innerhalb der gleichen Sekunde heraus filtern. Das liegt daran, dass ich es halt ganz billig implementiert habe.
Vielleicht könnte man das ja über minsecs steuern.
Ich bau aber erst mal den fix, dass es die doppelten Nachrichten innerhalb der gleichen Sekunde filtert.

Danke für deine hilfreichen Tests.
Kannst Du vielleicht noch ein paar mal die Batterie wechseln oder den Sensor resetten? Mich würde doch interessieren, ob es in den 36 bits nicht irgendwas gibt, was den Sensor identifiziert.

Grüße Sidey

[Ralf9]

Problem ist, dass ich die Länge 2x prüfe. Einmal vor dem Demodulieren und dann noch einmal nach dem ich es demoduliert und auch Längenseitig angepasst habe.

Eine Lösungsmöglichkeit wäre "lengthV_max" und ein  "lengthN_max" für die Länge vor und nach der Demodulation

Auch dazu habe ich ein issue geöffnet. Es ist ein Bug, sowohl im code als auch im Kommentar. Genau genommen, sollte der code wie er gedacht war, alles innerhalb der gleichen Sekunde heraus filtern. Das liegt daran, dass ich es halt ganz billig implementiert habe.
Vielleicht könnte man das ja über minsecs steuern.
Ich bau aber erst mal den fix, dass es die doppelten Nachrichten innerhalb der gleichen Sekunde filtert.

Wenn Du die doppelten gleichen Nachrichten innerhalb der gleichen Sekunde rausfiltern kannst ist es ausreichend.
Für den Rest reichen die minsecs

Kannst Du vielleicht noch ein paar mal die Batterie wechseln oder den Sensor resetten? Mich würde doch interessieren, ob es in den 36 bits nicht irgendwas gibt, was den Sensor identifiziert.

Ich hatte die Batterie schon oft draussen. Außer der ID in den ersten 8 Bit ändert sich nichts.

Gruß Ralf

[Sidey]

Hi Ralf,

also die Nachrichten innerhalb der gleichen Sekunde werden jetzt heraus gefiltert .. glaube ich zumindest.

Für den EAS800z habe ich minseqs und equalmsg entfernt und dafür die attribute event-on-update und event-min-intervall mit default werten gesetzt. (passiert natürlich nur beim autocreate)

Ich bin noch am überlegen, ob wir in state wirklich die Werte direkt hinein schreiben sollten oder nicht lieber das stateFormat vorbelegen, damit das gewünschte Ergebnis angezeigt wird. Das hätte den vorteil, dass man es leicht anpassen kann.

Grüße Sidey

[Ralf9]

also die Nachrichten innerhalb der gleichen Sekunde werden jetzt heraus gefiltert .. glaube ich zumindest.

Es hat sich nichts verändert

Code Auswählen Erweitern

2015.09.22 23:34:17 3: EAS800z converted to bits: 01001110 1 001 000011101011 1111 00111100
2015.09.22 23:34:17 3: EAS800z decoded protocolid: 7 sensor id=4E, channel=2, temp=23.5, hum=60, bat=ok
2015.09.22 23:34:17 3: EAS800z converted to bits: 01001110 1 001 000011101011 1111 00111100
2015.09.22 23:34:17 3: EAS800z decoded protocolid: 7 sensor id=4E, channel=2, temp=23.5, hum=60, bat=ok

und hier ist das Filelog des CUL_TCM97001:

Code Auswählen Erweitern

2015-09-22_23:51:21 CUL_TCM97001_21 T: 12.2 H: 75
2015-09-22_23:51:22 CUL_TCM97001_21 T: 12.2 H: 75
2015-09-22_23:51:22 CUL_TCM97001_21 T: 12.2 H: 75
2015-09-22_23:53:52 CUL_TCM97001_21 T: 12.2 H: 75
2015-09-22_23:53:53 CUL_TCM97001_21 T: 12.2 H: 75
2015-09-22_23:53:53 CUL_TCM97001_21 T: 12.2 H: 75
2015-09-22_23:56:23 CUL_TCM97001_21 T: 12.2 H: 75
2015-09-22_23:56:24 CUL_TCM97001_21 T: 12.2 H: 75
2015-09-22_23:58:54 CUL_TCM97001_21 T: 12.1 H: 75
2015-09-22_23:58:55 CUL_TCM97001_21 T: 12.1 H: 75

Gruß Ralf

[Hauswart]

So meine FA21RF sind gestern angekommen und ich habe den Signalduino gestern auch zusammengelötet. Eingebunden in FHEM ist er auch (sudo addgroup dialout [user]) hatte gefehlt

Leider habe ich wohl TX und RX falsch herum angeschlossen, so dass er keine Werte geloggt hatte - muss ich heute Abend ändern.


Empfänger und Sender hängen derzeit an einer 17cm Antenne, dies dürfte kein Problem darstellen?

Den Output zum FA21RF werde ich dir auf Github (https://github.com/RFD-FHEM/RFFHEM/issues/21) dann posten. Gruss

[Sidey]

Also eine Antenne für RX und TX parallel habe ich noch nicht versucht. Ob das ohne Auswirkungen funktioniert, kann ich dir nicht sagen.

Je nachdem, welchen Empfänger Du hast, brauchst Du auch keine Antenne.

Grüße Sidey

[Ralf9]

also die Nachrichten innerhalb der gleichen Sekunde werden jetzt heraus gefiltert .. glaube ich zumindest.

Ich glaube ich habe den Fehler gefunden. Das rausfiltern der doppelten Nachrichten innerhalb der gleichen Sekunde  funktioniert jetzt.


Das  "my %models = (..)"  in der "14_SIGNALduino_ID7.pm" wird wahrscheinlich nicht mehr benötigt.

Da so keine gescheitert Erkennung der Modelle möglich ist sollten wir vielleicht einfach die Modelle temp und temphum erzeugen und das nicht an der Modellbezeichnung der vorliegenden Sensoren fest machen.

Ein möglichkeit wäre:

Code Auswählen Erweitern

if ($hum == 0) {
$model = "temp_ID7";
} else {
$model = "temphum_ID7";
}

Sollen wir es so "temp_ID7" oder so "tempID7" schreiben?

Gruß Ralf

[Sidey]

Hi Ralf,

habe mir deinen commit angesehen. Ich hatte wohl Tomaten auf den Augen. Das konnte ja wirklich nicht funktionieren.
So sieht es plausibel aus. Danke.

In mymodels könnte man temp / temphum eintragen und dann die Bits für hum Auswerten.. Ich weiss halt nicht, welche Sensoren es halt sonst noch so gibt. Vermutlich aber nur temp und temphum..
Das wissen wir halt erst, wenn das mal jemand einsetzt.

Die Bits 24-27 scheinen womöglich ein Identifikationsmerkmal zu sein.

Was ich noch ändern würde, ist der Name des Moduls.
Es kann ja vom Prinzip auch mit anderen IO Geräten verwendet werden. Das würde ich im Namen auch berücksichtigen.

Ich würde es nach etwas ohne SIGNALduino benennen, irgendwas universales halt.

Grüße Sidey

[Ralf9]

Ich würde es nach etwas ohne SIGNALduino benennen, irgendwas universales halt.

Ich würde den Namen "14_SIGNALduino_ID7.pm" so lassen. So sieht man sofort wo es her kommt und wo es gepflegt wird.
Dich hat ja beim "14_CUL_TCM97001.pm" das "CUL" auch nicht davon abgehalten es zu verwenden.
Oder hast Du vor das "14_SIGNALduino_RSL.pm" und "14_SIGNALduino_AS.pm" auch noch umzubenennen?

Gruß Ralf

[Sidey]

Ich hätte da noch ein paar Argumente

Ja, das  RSL werde ich noch umbenennen, sobald es auch funktioniert... Ich kann es leider nicht testen,  habe keine RSL Geräte.

Das CUL TCM, ist kein gutes Beispiel, das hat weder etwas CUL spezifisches, noch funktioniert es nur mit dem TCM97001, der Autor benennt es nur nicht um, da sonst die bereits im Umlauf befindlichen Devices nicht mehr funktionieren würden. Ansonsten wäre Wetter1 oder sonstwas passender. Den Encoder Chip überkleben die Hersteller leider immer. Das wäre ja der korrekte Name.

Beim Fhemduino wurden die Module auch Fhemduino.... benannt, aber die waren ziemlich spezifisch gebaut, die laufen mit sonst nichts, bis auf das AS habe ich da auch nichts übernommen.

Das Cresta Modul hat auch keinen SIGNALDuino im Namen bekommen, aus genannten Gründen.

Das AS Modul, naja lassen wir das. Das Protokoll habe ich ja sozusagen selbst erfunden. Das wird keinem nutzen, solange ich keinen Transmitter Code veröffentlichte.

Ich würde weder SIGNALDuino noch ID7 im Namen belassen und zwar einfach aus folgendem Grund:

ID7 habe ich mir mal festgelegt.

Das Modul können wir unabhängig vom Signalduino zur Verfügung stellen. Wenn noch mal jemand das demodulieren des Signales in ein anderes IO Device integriert, dann findet er gleich ein passendes Modul.

Die Namentliche Verknüpfung in einem logischen Modul zu einem Physischen, würde ich nur herstellen, wenn es wirklich Abhängig ist. In unserem Fall ist es das nicht wirklich. Das verwirrt nur und führt dazu dass jemand das ganze noch mal in einem anderen Modul erfindet.

Egal wie wir es benennen, funktionieren wird es unabhängig davon.

Grüße Sidey

[Ralf9]

Zu Zeit habe ich 6 verschiende 433MHz Sensoren am Signalduino.

2x Logilink WS0002 (Temp, Humi)
1x Perl (Temp)
1x Lifetec LT3594 (Temp)
1x OREGON THGR328N (Temp, Humi, Bat)
2x Bresser (Temp, Humi, Bat)

Hallo Jörg,

Welche Bezeichnung hat der Perl Sensor?
Hat der Lifetec LT3594 ein Display?

Könntest Du bei den Sensoren auch noch dazuschreiben welches Modul (wie z.B. Cresta oder CUL_TCM97001) benutzt wird.

Gruß Ralf