Signalduino Entwicklung

[GregPac]

Hi Greg,

Das Signal sieht ähnlich dem aus, welches die Sensoren im tcm97001 Modul verwenden.
Durch die Toleranzen wird es an das Modul übergeben.

Allerdings gibt es ein paar Abweichungen. Sieht so aus, als ob ein anderer Encoder Chip verwendet wird.

Hast Du als Vergleich auch einen anderen Sensor aus der tcm97001 Reihe?

An Livolo habe ich etwas geschraubt.
Dein Taster sollte in Bits dekodiert werden. Mach mal ein Update.

Allerdings ist das eine seltsame Modulation nach den Dokumentationen, welche ich im Internet gefunden habe.
Da gibt es für eine 0 bzw.  1 zwei Mögliche Signalzustände. Da bin ich mir noch nicht sicher, wie ich das berücksichtige, bislang ist mir so was noch nicht unter gekommen.


Grüße Sidey

Hi,
hab heute nochmal ein Update gemacht,
mein Auriol wird jetzt erkannt. Als Modell wurde jetzt autom. Mebus  gesetzt

Bist du mit den Livolo evtl. schon etwas weiter?

Gruß
Greg

[Sidey]

Hi,
hab heute nochmal ein Update gemacht,
mein Auriol wird jetzt erkannt. Als Modell wurde jetzt autom. Mebus  gesetzt

Bist du mit den Livolo evtl. schon etwas weiter?

Gruß
Greg

Hi GregPac,

na das ist doch mal was.
Bezüglich Livolo habe ich die letzten Tage nichts spezielles gemacht.

Ich habe ein paar Änderungen gemacht, mit denen man die Wiederholen auswerten kann.
Bei dem Livolo ist die Herausforderung, dass es vier Signalmuster gibt mit denen ein Bit dargestellt wird. Die anderen Signalcodierungen, mal abgesehen einer Manchester Codierung, haben zwei Signalmuster.
Da ich das im Fhem Modul bislang nicht vorgesehen habe, kann man das jetzt nicht so einfach implementieren.

Was man jetzt machen könnte, wäre einen Filter einzusetzen, der die vier Signalcodes in zwei reduziert.

Ich will jetzt aber erst mal eine Stabile Version veröffentlichen, bevor ich wieder Neuerungen Einbau.

Sidey

[Sidey]

Hallo allerseits,


der Support für das Hideki Protokoll, welches Sensoren von Cresta, Hama, Bresser, TFA und anderen wurde heute in die "normale" Version aufgenommen.
Aktuell werden dort Temp/Hydro Sensoren unterstützt. Wer noch andere Sensortypen hat, kann sich gerne mit Daten melden.


Vielen Dank auch an Ralf9, HJGode und pejonp (ich hoffe ich habe niemand vergessen), die bei der Entwicklung maßgeblich beteiligt waren.

Grüße Sidey

[Kuzl]

Halle Sidey,

ist es möglich, den Signalduino über das Netzwerk einzubinden?
Ich denke da an Socat oder an die Transparent Bridge mit dem ESP8266 http://www.esp8266.com/viewtopic.php?f=6&t=864&start=40
Im Weiteren Wäre denkbar, das Ganze anstatt auf einem Arduino direkt auf dem ESP8266 laufen zu lassen.

Viele Grüße,
Kuzl

[Ralf9]

ist es möglich, den Signalduino über das Netzwerk einzubinden?

Habe ich mir auch schon überlegt. Machbar ist vieles.

Bei Socat brauchst Du trotzdem noch ein extra Raspi o.ä. auf dem socat läüft.
Ich würde es eher mit sowas machen:
http://www.ebay.de/itm/Mini-W5100-Ethernet-Shield-Network-Expansion-Board-For-Arduino-/201394383381?hash=item2ee40a6a15
oder
http://www.ebay.de/itm/Upgrade-NANO-W5100-Ethernet-Shield-for-Arduino-Nano-/181537948032?hash=item2a44814180

Dies zu realisieren wäre aber etwas aufwendiger. Evtl ein Projekt für den Winter.
Damit könnten dann mehrere Signalduino an fhem angebunden werden.
So ähnlich wie bei Homematic Funk oder wired. Dort gibt es in fhem mehrere LAN-Gateways. Jedes LAN-Gateway ist ein eigenes IODev.

Gruß Ralf

[Sidey]

Hi Kuzl,


Aktuell ist es leider noch nicht möglich den Signalduino über das Netzwerk einzubinden.


Dkahn hat sich damit schon mal beschäftigt, aber ich weiss nicht welche Ergebnisse er erzielt hat.

Insgesamt stellt der Speicher verbrauch aktuell ein Problem dar. Die Variante mit einem ESP8226 scheint da noch am ehesten funktionieren zu können, da keine Libs notwendig erscheinen.

Ob der Signalduino auch komplett auf dem Esp8266 läuft weiss ich nicht. Dazu müsste man prüfen, ob er genügend RAM/Flash und Interrupts hat.

Die Netzwerk Einbindung des Fhem Moduls habe ich nicht getestet,  aber die könnte schon funktionieren, da ich nichts gemacht habe, was es verhindern könnte.


Die Einbindung mit dem ws5100 chip wird vermutlich nicht klappen.
Dazu müsste ich den arduino code ordentlich optimieren, gut das habe ich ohnehin vor, aber ob es dann läuft.  Da bin ich doch unsicher.

Grüße Sidey

[Sidey]

Post gelöscht, da doppelt

[Kuzl]

Wenn man in FHEM anstatt des Devices auch einfach die IP+Port angeben kann, dann sollte zuminderst die Sache mit socat schon funktionieren.
Auch Die Transparent Bridge des ESP8266 macht im Grunde nichts anderes wie socat.
Zu den Speichergrößen kann ich dir auf Anhieb nichts sagen, denke aber, dass das klappen sollte.

Alle 3 Varianten wären ein super Gewinn, da man dann den Signalduino mehr oder weniger da plazieren kann, wo er benötigt wird.

[Ralf9]

Da mir das mit der whiteIdList so noch nicht so richtig gefällt, habe ich es gestern bei mir etwas umgeschrieben.

In einer sub IdList werden mit foreach alle ids durchlaufen und dann je nach Nachricht (MS,MU und MC) in 3 Hash verteilt.
Die whiteIdList wird dabei berücksichtigt.

Es ist fast fertig, ich weiß aber nicht wie ich überprüfen kann ob ein hash wie z.B. %muIdList Daten enthält.

Hier ist die definition das Hash:
my %muIdList = ();

z.B. in der Parse Routine möchte ich die SIGNALduino_Parse_MU nur aufrufen, wenn der %muIdList hash was enthält.

Code Auswählen Erweitern

if (%muIdList ist nicht leer)
{
$dispatched= SIGNALduino_Parse_MU($hash, $iohash, $name, $rmsg,%signal_parts);
}

Gruß Ralf

[Sidey]

Hi Ralf,

Wäre es nicht einfacher die Protokoll Liste in einen Separaten Hash zu laden und dort nur die Werte zu übernehmen, welche in der whitelist stehen?

[Ralf9]

Wäre es nicht einfacher die Protokoll Liste in einen Separaten Hash zu laden und dort nur die Werte zu übernehmen, welche in der whitelist stehen?

Nein, damit erreiche ich nicht, den Vorteil den ich damit erreichen will.

Es gibt 3 hashes die für die entsprechende Nachrichtenart (MS, MU und MC) nur die notwendigen ids enthalten.

z.B. bei der MS_Parse Routine wird dann aus

Code Auswählen Erweitern

foreach $id ( keys %ProtocolListSIGNALduino) {
das hier

Code Auswählen Erweitern

foreach $id ( keys %msIdList) {

Da dann in der foreach nur noch die notwendigen ids durchlaufen werden, fallen auch die "next if" Abfragen weg.

Gruß Ralf

[Sidey]

Nein, damit erreiche ich nicht, den Vorteil den ich damit erreichen will.

Es gibt 3 hashes die für die entsprechende Nachrichtenart (MS, MU und MC) nur die notwendigen ids enthalten.

z.B. bei der MS_Parse Routine wird dann aus

Code Auswählen Erweitern

foreach $id ( keys %ProtocolListSIGNALduino) {
das hier

Code Auswählen Erweitern

foreach $id ( keys %msIdList) {

Da dann in der foreach nur noch die notwendigen ids durchlaufen werden, fallen auch die "next if" Abfragen weg.

Gruß Ralf

ok, wenn pro Nachrichtentyp eine eigene Liste her soll, dann können wir drei Listem erstellen. Wir brauchen dann weiterhin nur einen hash.

Beispiel um Protokoll 1,5 und 12 in der Schleife zu durchlaufen:

Code Auswählen Erweitern


foreach $id ( @{1,5,12})


Die Listen kann man ja beim define oder bei set whitelist id aktualisieren und in den Gerätehash speichern.



Sidey

[hjgode]

Hallo

also ein ESP8266 ist mit sich selbst zu stark beschäftigt, so dass er nur sehr eingeschränkt Interrupts verarbeiten kann. Da nützt dem ESP8266 auch sein größerer Speicher nix.

Über das AT Interface wäre es aber ein leichtes die Daten statt über USB über HTPP Get an den FHEM Server zu übermitteln.

Über Ws5100 wird wohl auf nem Arduino Uno/Nano/Mini auch nix gehen, das RAM ist ja schon ziemlich ausgelastet.

~Josef

Hi Kuzl,

...
Insgesamt stellt der Speicher verbrauch aktuell ein Problem dar. Die Variante mit einem ESP8226 scheint da noch am ehesten funktionieren zu können, da keine Libs notwendig erscheinen.

Ob der Signalduino auch komplett auf dem Esp8266 läuft weiss ich nicht. Dazu müsste man prüfen, ob er genügend RAM/Flash und Interrupts hat.

Die Netzwerk Einbindung des Fhem Moduls habe ich nicht getestet,  aber die könnte schon funktionieren, da ich nichts gemacht habe, was es verhindern könnte.


Die Einbindung mit dem ws5100 chip wird vermutlich nicht klappen.
Dazu müsste ich den arduino code ordentlich optimieren, gut das habe ich ohnehin vor, aber ob es dann läuft.  Da bin ich doch unsicher.

Grüße Sidey

[hjgode]

Hi nochmal

ist eigentlich Eurochron noch drin?
Habe gerade drei Sensoren bekommen und schon ma einen angeworfen. Könnte sein, dass der das hier im SignalDuino produziert:

Code Auswählen Erweitern

2015.10.14 18:34:40 1: DEBUG>sduino padded 0 bits to bit_msg array
2015.10.14 18:34:40 5: converted Data to (u7#5980C7F37)
2015.10.14 18:34:40 5: sduino dispatch u7#5980C7F37
2015.10.14 18:34:40 4: SIGNALduino_unknown incomming msg: u7#5980C7F37
2015.10.14 18:34:40 4: SIGNALduino_unknown rawData: 5980C7F37
2015.10.14 18:34:40 4: SIGNALduino_unknown Protocol: 7
2015.10.14 18:34:40 4: SIGNALduino_unknown converted to bits: 010110011000000011000111111100110111
2015.10.14 18:34:40 4: SIGNALduino_unknown decoded protocolid: 7 (TX70DTH) sensor id=59, channel=0, temp=19.9, hum=55, bat=ok

2015.10.14 18:34:40 4: SIGNALduino_unknown decoded protocolid: 7 (EAS800z / type=5) mode=auto, sensor id=9, channel=1, temp=19.9, hum=55, bat=ok

2015.10.14 18:34:40 4: SIGNALduino_unknown incomming msg: u7#5980C7F37
2015.10.14 18:34:40 4: SIGNALduino_unknown rawData: 5980C7F37
2015.10.14 18:34:40 4: SIGNALduino_unknown Protocol: 7
2015.10.14 18:34:40 4: SIGNALduino_unknown converted to bits: 010110011000000011000111111100110111
2015.10.14 18:34:40 4: SIGNALduino_unknown decoded protocolid: 7 (TX70DTH) sensor id=59, channel=0, temp=19.9, hum=55, bat=ok

2015.10.14 18:34:40 4: SIGNALduino_unknown decoded protocolid: 7 (EAS800z / type=5) mode=auto, sensor id=9, channel=1, temp=19.9, hum=55, bat=ok

2015.10.14 18:34:40 5: Triggering sduino (1 changes)
2015.10.14 18:34:40 5: Notify loop for sduino UNKNOWNCODE u7#5980C7F37


Der Sensor ist ein EAS800Z.

~josef

PS: 433MHz Empfangsprobleme vorrübergehend erledigt. Eine WIP Antenna braucht auch ein bisschen Erde. Werde mal noch eine Wip Ground Plane bauen.

[Ralf9]

ist eigentlich Eurochron noch drin?

der EAS800Z ist aktuell nicht drin, aber das Einbauen dürfte kein Problem sein.

Einfach  in der 00_SIGNALduino.pm

Code Auswählen Erweitern

."SD_WS07:"
in die $clientsSIGNALduino Liste anhängen und

Code Auswählen Erweitern

"9:SD_WS07" => "^P7#[A-Fa-f0-9]+",
in die matchlist kopieren

Und dann noch die "14_SD_WS07.pm" vom dev-proto7 ins FHEM Verzeichnis kopieren

Gruß Ralf