eBus -> 868 Mhz Schnittstelle

Begonnen von JimKnopf, 19 Juni 2014, 11:59:21

Vorheriges Thema - Nächstes Thema

JimKnopf

Hallo Miteinander!

Ich arbeite gerade an einer Schnittstelle eBus (Wolf) -> 868 MHz.
Als Controller benutze ich den Atmega88 (solange der Speicher reicht, sonst wird erhöht), ein 4011 mit wenigen Bauteilen zur eBus Konvertierung und dem Empfänger aus FS20 Universalempfänger und dem Sender aus FS20 Universalsender.
Da ich die Funkmodule direkt verwende ohne den Controller von eQ-3 kann ich das Protokoll frei wählen. Bislang ist meine Idee mich an das FS20 Protokoll zu halten aber eine andere Checksumme zu verwenden um zwischen den Modellen FS20/FHT und VEBC (Venus eBus Konverter) unterscheiden zu können.
Da ich noch nicht die geringste Ahnung habe, wie in FHEM Sender Modulen zugeordnet werden wollte ich die Profis fragen, ob ich ein anderes Protokoll verwenden sollte und welche Checksummen, bzw. Summanden für die Quersumme verwendet werden sollten. Bislang weiß ich nur, das Quersumme + 6 für FS20 steht und Quersumme + 12 für FHT.

Würde mich über jeden Hinweis freuen.

Gruß,
Burkhard
FHEM,LaCrosse,PCA301,Revolt,MAX!,HM,FS20, MQTT2, ebusd 3.4.v3.4-96-g96d5623, ebus Adapter 3.0 mit 20201219-offset , Wolf  CGB (-K)-20, Wolf ISM7, Wolf Solar SM, Speicher/WR E3DC S10, eGolf, Keba P30, Phoenix Contact EV, OpenWB

betateilchen

FS20 halte ich irgendwie für eine unglückliche Wahl.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rudolfkoenig

Der Haken an FS20 ist, dass man nur ca 160 Nachrichten pro Stunde versenden darf, bzw. 3-mal soviel, wenn man auf die Wiederholungen verzichtet (1% Grenze). Weiterhin kann man relativ wenig Information (5 Bytes) pro Nachricht senden, obwohl culfw mWn das nicht begrenzt. Die Datenuebertragung ist mit 1kHz auch noch langsam.

Wenn man alles selbst baut, wuerde ich auf einem CC1101 im Paketmodus setzen, wie HomeMatic, MAX oder culfw/RFR, und die Daten in RFR-Modus senden. culfw muss nicht geaendert werden, nur ein FHEM-Modul fehlt.

Heisst aber nicht, dass FS20/FHT/EM/S300 oder gar HomeMatic nicht gangbar waeren.

P.S.: diese Angaben sind mit Vorsicht zu geniessen, ich bin kein Hardware-Mensch.

justme1968

#3
schau dir mal das SWAP protokoll der panstamps an. eventuell ist das auch eine alternative für dich. da bist du flexibler als mit homematic und ich denke auch etwas sparsamer was den speicherbedarf angeht. das protokoll ist recht schlank und (mit einschränkungen) bidirektional. es gibt eine optionale verschlüsselung.
für die fhem seite gibt es ein universelles modul das erweiterbar ist um weiterführende anforderungen umzusetzen.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

betateilchen

Zitat von: justme1968 am 19 Juni 2014, 12:53:45
um weiterdürfende anforderungen

Hast Du schon wieder die Autokorrektur eingeschaltet?
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

justme1968

hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

JimKnopf

Hi!

Vielen Dank für die schnellen Antworten!
Die Rahmenbedingungen für mein Projekt sind : Sender und Empfänger aus dem ELV Paket, ohne deren Controller.
Kein umschalten oder zweiten CUL notwendig werden lassen.

FS20 + FHT benutzten ja für die Modulation 2*400/2*600µs
FM1010 nutzt 400+400/ 400+800 µs
Das sind die Parameter an denen ich schrauben möchte, z.B.: 0 = 200µs high+200µs low / 1 = 300µs high + 300µs low oder gleich 100 und 200 µs?
Das wäre ja schonmal doppelte Geschwindigkeit, dann dazu 10 Bytes?  Da im Empfangsbereich sicher nicht viele Heizungsanlagen liegen könnte man sicher auch auf 2* Hauscode verzichten.
Mit neuen Bausteinen möchte ich mich nicht beschäftigen, denn dann muss ich wieder mit den Spezifikationen kämpfen, SMD Bauteile sind auch nicht gerade praktisch auf einer Lochrasterplatine ;).
Dazu kommt, das ich mich mit Perl (noch) so gut wie gar nicht auskenne und es natürlich am einfachsten ist, ein bestehendes Modul entsprechend umzustricken. Vielleicht findet sich aber auch jemand der sich mit so was auskennt ;).

Vielleicht habt ihr ja Tipps, wie ich optimalere Werte nehmen kann, ohne die Elektronik ändern zu müssen.
Besteht überhaupt allgemeines Interesse an dieser Schnittstelle? Lohnt die Arbeit?

Gruß,
Burkhard
FHEM,LaCrosse,PCA301,Revolt,MAX!,HM,FS20, MQTT2, ebusd 3.4.v3.4-96-g96d5623, ebus Adapter 3.0 mit 20201219-offset , Wolf  CGB (-K)-20, Wolf ISM7, Wolf Solar SM, Speicher/WR E3DC S10, eGolf, Keba P30, Phoenix Contact EV, OpenWB

JimKnopf

So, hab mir jetzt zwei CC1101 Module bestellt, mal gucken wie ich damit zurecht komme. :)
FHEM,LaCrosse,PCA301,Revolt,MAX!,HM,FS20, MQTT2, ebusd 3.4.v3.4-96-g96d5623, ebus Adapter 3.0 mit 20201219-offset , Wolf  CGB (-K)-20, Wolf ISM7, Wolf Solar SM, Speicher/WR E3DC S10, eGolf, Keba P30, Phoenix Contact EV, OpenWB