Posts by nurazur

    1. Bedeutet der Datenpunkt 'FEI' in Protokoll V1.1 und der Datenpunkt 'Frequency offset' in Protokoll V2.0 das selbe?

    nicht ganz. "FEI" bedeutet 'Frequency Error indicator' und ist eine Zahl ohne Einheit, die die Anzahl der Schritte angibt die der Empfänger-Oszillator gebraucht hat um sich auf die Senderfrequenz abzustimmen. (ähnlich wie bei einem UKW Radio wo man früher an der Kurbel gedreht hat bis man einen Kanal gefunden hat).

    Die Groesse der Schritte in Hz ist spezifisch für den verwendeten Typ Transceiver IC . Beim RFM69xxx sind das etwa 61Hz, beim CC1101, den ich in Zukunft auch unterstützen moechte, sind es etwa 397 Hz pro Schritt. Deshalb finde ich es besser wenn man den Versatz in Hz ausgibt.


    2. Wird die RFM69-Temperatur im Protokoll V2.0 nicht mehr übertragen?

    Nein. Da die Temperatur mit +/- 3K sowieso sehr ungenau ist und nur als Debug-Wert gedacht war, lasse ich das weg. Man kann trotzdem am Gateway einen richtigen Temperatursensor einsetzen, wenn man das will, aber ich weiss nicht ob das sinnvoll ist. Es ergibt - für mich - mehr Sinn, wenn man so einen Temperatursensor unabhängig vom TiNo am Raspberry Pi anschliesst, der kann per crontab die Messungen regelmäßsig durchführen.


    Der Grund warum ich den Wert überhaupt erfasst hatte war herauszufinden, ob es möglich ist die gemessene Temperatur zur Kompensation der Temperaturdrift des Quarzes zu verwenden.

    (ja, aber nur wenn der Sensor kalibriert ist, aber ich habe bisher keine gute Lösung wie man den kalibrieren könnte)

    3. Nochmal zu den Interrupts, aber diesmal im Protokoll V2.0. Dieser ist in deiner Protokollbeschreibung V2.0 (letzte Seite) noch als 8bit hex dargestellt und nicht weiter beschrieben. Wolltest du den nicht erweitern

    doch... kommt... du sagtest doch ich soll mir Zeit lassen. Entwurf als PN.

    Es gibt eine neue Firmware für das Tino Funksystem!


    Der TiNo Firmware Update 2.0.1 ist jetzt auf github. Die Version ging von 1.x auf 2.x weil es Inkompatibilitäten gibt, die aber NICHT das Funkinterface betreffen. Das heisst, alle TiNo's die mit Sketchen der Versionen 1.x geflasht wurden sind vom Funkprotokoll her voll kompatibel mit der neuen Version.


    Bei dem Update geht es vor allem um zwei Bereiche:

    1. Erweiterung der Funktionalität. TiNo Empfänger koennen jetzt als "Aktoren" dienen, also Licht ein/ausschalten, Thermostaten regeln etc, eigentlich genau wie ein Homematic System. Allerdings muss ich die entsprechende Dokumentation erst noch fertig stellen.


    2. Noch mehr Sensoren: neben den bekannten HTU21D, SHT2x und SHT3x werden jetzt DS18B20 und BME280 unterstützt. Da der Speicherplatz im Atmega328 aber zu klein für alle ist, muss der jeweilige Sensor vor dem Kompilieren mittels Kompiler-Switch ausgewählt werden.


    Wer bereits die "Tiny Nodes" im Board Manager der Arduino IDE installiert hat, kann nun einfach auf Version 2.0 erhoehen.


    Neu ist:

    1. Als Empfänger kann der TiNo Aktionen ausführen, die man frei definieren und im EEPROM ablegen kann. Man kann festlegen, auf welchen der 4 moeglichen Interrupts reagiert werden soll, wie reagiert werden soll, also welcher Port angesprochen werden soll und auf welchen Sender reagiert werden soll. Moegliche Kommandos sind "AN", "AUS" "Toggle" (ändere den Port-Zustand) und "Puls". Die Zeitdauer eines Pulses kann ebenfalls konfiguriert werden.
    2. das serielle Interface des Empfänger-Sketches. Dies ist von jetzt an dem ursprünglichen Protokoll des TinyRx4 sehr ähnlich, mit einer Reihe von Erweiterungen. Ausserdem werden die ankommenden Pakete besser auf Plausibilität geprüft.
    3. Die Prüfsumme des Eeproms ist jetzt CRC-16, das ist zuverlässiger als die 8-bit Prüfsumme bisher.
    4. Die Temperaturdrift des Quarzes auf dem RFM Modul kann kompensiert werden. Das ist eigentlich nicht notwendig, hat aber Vorteile wenn man den TiNo in extremen Umgebungen betreiben will. Im Moment ist die Funktion im Sketch auskommentiert.
    5. Die Batteriespannung wird jetzt während dem Sendepuls gemessen. Das erlaubt eine wesentlich bessere Abschätzung des Zustandes der Batterie. Mit zunehmender Entladung nimmt der Innenwiderstand der Batterie zu, gegen Ende der Lebensdauer wird das der bestimmende Faktor, während die Leerlaufspannung durchaus noch vernünftig ist. Das RFM69 Modul bricht bei etwa 1.7V Betriebsspannung zusammen.
    6. die Python Skripte zum Konfigurieren der TiNo's sind jetzt kompatibel mit Python Version 3. Achtung, diese Skripte sind nicht mit TiNo Version 1.1 kompatibel. wer also noch Sensoren im Netzwerk hat die mit TiNo Version 1.x konfiguriert werden, der sollte sich die alten Tools unbedingt aufheben.
    7. neue Bootloader und neue Fuses: Da der Flashspeicher langsam knapp wird, verwende ich optiboot Bootloader, die benoetigen gerade mal 512 Bytes im Flash.





    Ich meinte welches Format hat diese Zahl im jetzigen Protokoll V1.1?

    HEX

    ja das ist soweit richtig.

    Aber ich dachte wir hätten uns darauf geeinigt dass ich für die Version 2.0 das Interface dem TinyRX4 angleiche. dann kann man nämlich sowohl den TiNo als auch den TinyRX mit dem selben ioBroker Adapter betreiben. Ich bin gerade dabei die Version2.0 auf Github hochzuladen, mit dem TinyRX Interface.

    Eine Interface Spezifikation habe ich auch, die ist aber leider noch nicht 100%ig fertig.

    Für die Interrupts moechte ich deinen Vorschlag für jeden interrupt 2 bits zu verwenden umsetzen. Das Heartbeat Flag ist in diesem Zusammenhang eigentlich unwichtig, weil es in der jetzigen Form keine Aussagekraft hat:

    Ist das Interrupt Byte Null, dann handelt es sich um ein reguläres Paket, d.h. das Heartbeat Flag ist 1.

    Ist das Interrupt Byte ungleich Null, dann handelt es sich um ein nicht reguläres, von einem Interrupt ausgeloestes Paket.


    Anbei die 2.0 Spec in ihrer jetzigen Form, ich mach's fertig so schnell ich kann, kann aber morgen werden. Ist aber wirklich mitten in der Bearbeitung, koennen also Tippfehler drin sein etc.

    Also von der Platine gemessen so 80mm bei 868MHz?

    ja genau.


    Theoretisch müssten sich ja auch annährend gleiche Temperaturen einstellen, wenn die einfach nur längere Zeit offen auf dem Tisch liegen. Ich werde das Mal protokollieren...

    Ich muss gestehen ich habe das nie genau untersucht, und habe den Angaben des Herstellers vertraut. Aber 2 bis 3K Unterschied zwischen 2 Teilen habe ich noch nie gemessen.

    Im Grunde kann der TiNo für so ziemlich alle Meldungen von Wasserrohrbruch bis Klingel, Briefkasten offen und Brief drin, Garatentor zu oder auf usw. verwendet werden. Und ich könnte einen TiNo ins Auto einbauen und über einen Taster das (Garagen-)Tor öffnen, Licht einschalten und wüsste immer wie warm es im Auto ist. Mit einem Erschütterungssensor (oder direkt einen Kontakt an die Zündung) wüsste ich auch wenn sich mein Auto (autorisiert oder unautorisiert) vom Acker macht :-)

    richtig. Schoen wäre es zu wissen wer den TiNo wo wie einsetzt und evtl. auch eine Anleitung dazu postet.

    Kann ich auf dem TiNo LC eigentlich auch ein RFM69-HCW Modul verbauen? In der Konfig kann ich ja das passende RF-Modul auswählen.

    nein. Die Konfiguration dient dazu dass man auf den TiNo-LC oder den TiNo-HP die identische Firmware flashen kann. Nenne es Faulheit. Es ist einfach umständlich für jede Konfiguration einen neuen Sketch kompilieren zu müssen. Bei den TinyTx4 Modulen ist das der Fall.

    Gibt es Vorgaben für die (beste) Antenne? Material, Dicke, Länge? Welchen Draht verwendest Du?

    Das ist ein sehr komplexes Thema. Ein paar Faustregeln:

    Die Dicke des Drahtes spielt keine praktische Rolle, ich nehme normalen Klingeldraht.

    Die Länge der Antenne soll lamda/4 sein minus 5%, da wir uns nicht im Vakuum befinden.

    Die Antenne soll nicht komplett ins Gehäuse eingebaut werden, ausser du nimmst erhebliche Sendeverluste in Kauf.

    Die Antenne soll immer von der Leiterplatte wegzeigen, egal in welche Richtung. Sie bildet -sehr vereinfacht ausgedrückt - zusammen mit der Leiterplatte einen Dipol. Ich habe gute Erfahrungen damit gemacht den Antennendraht teilweise ins Gehäuse zu verlegen und ca 25 -30mm herausschauen zu lassen.

    Wenn du externe Antennen verwendest, immer auf den Typ achten. Manche haben ganz erhebliche Richtwirkung. Daumenregel: je hoeher der Antennengewinn (in dBi) desto hoeher die Richtwirkung. Manchmal ist das ja durchaus erwünscht. Viele gekaufte Stabantennen sind in keinster Weise besser als ein Draht. Auch diese Antennen brauchen die Leiterplatte als Gegengewicht.


    Gibt es noch einen Tipp zum löten von dem RF-Modul? Hab das Gefühl, links, der erste Pin von unten und der rechts der zweite Pin von unten lassen sich sehr schlecht löten. Liegt das an der TiNo Platine oder am Modul selber? Masseflächen? Irgendwo muss die Hitze ja hin..

    Das liegt sowohl an der Massefläche des Moduls als auch an der Massefläche der Leiterplatte, wobei letztere auf gute Loetbarkeit entwickelt wurde und wahrscheinlich weniger eine Rolle spielt. Einen besnderen Tipp kann ich dir nicht geben, ausser: du musst geduldig sein... Ich stelle die Loettemperatur etwa auf 300 degC ein, dazu beeile ich mich dann aber auch bei den anderen Loetstellen.



    Wenn man den Filter über dem HTU21D verwenden möchte, kommt der dann auf die Platine oder klebt man den besser ins Gehäuse?

    Ich stecke ihn auf die Platine und klebe die Leiterplatte ins Gehäuse. Da wo der Filter ist mus man vorher natürlich noch ein Loch bohren, ca 6mm Durchmesser.



    Aber die Temperaturen liegen 2K bis 3K auseinander.

    Dann liegen die Temperaturen auch sehr wahrscheinlich soweit auseinander. Ich hatte die TiNo's (ohne Gehäuse) getestet und die Temperaturwerte waren alle OK.

    Hast du für ausreichend Luftzufur in den TiNo Gehäusen gesorgt? Ich hatte keine Loecher in die Gehäuse gebohrt, weil ein bisschen Basteln muss schon sein! Kannst du evtl. den Versuch ohne die Gehäuse wiederholen? Mehr als 0.2 bis 0.3 K sollten die Teile dann nicht unterschiedlich sein. Ich hatte noch nie Probleme damit.

    Die drei Interupts kann ich verwenden, in dem ich den entsprechenden Pin auf GND ziehe? Der Adapter unterstützt das aber noch nicht, oder?

    richtig. Im Prinzip sind die Interrupts bereits verwendbar. Sie sind bitcodiert im letzten Parameter des 'data' Teils.

    NodeId,66,s=-52.50,data:OK;1655;195;3140;69.50;1;,FEI=-16,T=37,biterrors=0

    Hier ist es '1'. Die '1' besagt nur dass das System in Ordnung ist ("heart beat"). Interupts sind in den bits 1 bis 4 codiert, eine Null heisst "kein Interrupt ausgeloest" und eine '1' heisst"es wurde ein Interrupt ausgeloest". Also wenn der Parameter '4' ist, ist das binär b0 0100, d.h. der Interrupt #2 wurde ausgeloest. Also, Interupt #1 steht für die 2, Interrupt #2 für die 4, etc.


    Aber ich werde das Anfang September in der Interface Spezifikation genau darstellen. Das gegenwärtige Interface gibt es dann nicht mehr, ich passe mich dem TinyRx4 Interface an.


    Wollte nur "Mal eben" Python unter Windows installieren und ein Skript testen. Google Suche: Python Download Windows... und man bekommt natürlich erst Mal Python3. Dann versuch Mal ein Downgrade auf Python2 zu machen... aaargh und bis dann die serielle Schnittstelle läuft sind aus "mal eben" ein paar Stunden geworden.

    auf dem Raspberry Pi unter Raspbian ist Python in beiden Versionen vorinstalliert.... nur so als Tip.

    Auf dem Windows PC ist das ein wenig komplizierter, aber eigentlich nicht viel. Man muss nicht einmal mehr die Pfad Variable selbst einstellen.

    Die Installation des serial -Moduls ist eigentlich recht einfach, aber ich versteh' schon, wenn man das noch nie gemacht hat, dauert es halt.


    Ich habe übrigens zum Testen Python2.7 und Python 3.7 parallel auf dem Win10 Rechner am Laufen, zu dem Zweck hab ich bei Python 3 die "Python.exe" in "Python3.exe" umbenannt. Das ist zwar brutal, aber so kommen sich die Python Versionen nicht in die Quere.


    Im Anhang das Tool mit Python3 Unterstützung, Python2.7 sollte auch noch funktionieren!

    Bitte noch in der Doku ergänzen, dass es nur unter Python2 und nicht unter Python3 läuft.

    oh - das habe ich glatt vergessen! Wird schnellst moeglich auf Python3 umgestellt.


    Edit:

    eine Sauarbeit! Eigentlich hätte ich gedacht das geht ganz schnell mit dem 2to3.py Skript, aber Pustekuchen. Ich muss alles was unter Python2 als String läuft auf Bytes umstellen. Eine Frickelei. Ich hasse Python3 jetzt schon.

    Sehe ich das richtig, dass es aktuell nur möglich ist den HTU21D und den SHT3x auszulesen?

    SHT3x SHT2X


    das ist richtig. Aber man kann auch digitale "Ereignisse" wie z.B. einen Fensterkontakt oder das Ausloesen eines Bewegungsmelders übertragen. Ich habe auch Sketches für BMP280, SHT3X und DS18B20 in Vorbereitung (also, funktioniert schon, aber muss in eine Form gebracht werden dass man es auch veroeffentlichen kann).

    Bin derzeit im Urlaub, ich hoffe ich kann es Anfang September auf Github raufladen. Wird ein grosses Update.

    Was muss ich denn für die 1MHz beim Sender bzw. die 8MHz beim Gateway auswählen, jeweils mit und ohne Quarz?

    was meinst du mit Quarz? Moechtest du einen 8MHz Quarz verwenden (bessere Präzision des seriellen Interfaces, hoehere Baudraten moeglich) oder einen Uhrenquarz mit 32,768 kHz (niedrigster moeglicher Ruhestrom)?


    Gateway läuft immer so schnell wie moeglich, also am Besten mit 8MHz Quarz. Das Gateway hat keinen Schlafmodus, man braucht also keinen Uhrenquarz. Mit 8MHz Quarz ausgestattet ist der TiNo mit dem Arduino Pro-Mini identisch. Also in der IDE den Arduino Pro-Mini auswählen (3.3V Variante) und auf "burn Bootloader" klicken.


    Desweiteren musst du dir überlegen ob du lieber mit oder ohne Bootloader arbeitest.

    Geliefert wird der TiNo immer MIT Bootloader.


    Würde es nicht reichen die vier Varianten der AVRDUDE Argumente in der Doku zu hinterlegen?

    sind doch hinterlegt:


    Variante auswählen, COM Port des Programmers einstellen, Programmer Typ einstellen, und auf "Burn Bootloader" klicken. Das muss man auch machen, wenn man keinen Bootloader verwenden will.

    Die Fuses sind in der boards.txt hinterlegt die mit dem TiNo Modul für die Arduino IDE geliefert weden.


    -U lfuse:w:0x63:m -U hfuse:w:0xd9:m -U efuse:w:0xff:m

    leider total daneben, du tust dir keinen Gefallen wenn du da rumprobierst und dich nicht auskennst. Im schlimmsten Fall machst du den TiNo inoperabel!

    Wenn noch jemand noch irgendwelche Ideen hat, immer her damit.

    Spontan fallen mir 2 Dinge ein:


    1. Ueberwachung der VCC der Sensoren. Z.B. eine Warnung ausgeben wenn die Spannung unter 2V gefallen ist. Dann sollte man die Batterie dringend wechseln.


    2. Uberwachung der Synchronisation mit dem Rolling Code. Da muss ich mir allerdings noch Gedanken machen wegen der Re-synchronisation, z.B. nach einem Batteriewechsel. Wenn die Synchronisation verloren ist, eine Warnung ausgeben und den Datenpunkt ignorieren. Denn es kann sich ja um eine Fake-Message des boesen Nachbarn handeln.


    Könnte man auf diesen Sensor (CCS811 CO2 eCO2 TVOC) an den Tino dran hängen?

    selbstverständlich. Allerdings frage ich mich ob das mit Batterie sinnvoll ist, da der Sensor echt viel Strom zieht.

    Das hier finde ich im Datenblatt:

    the conditioning period is the time required to achieve good sensor stability

    before measuring VOCs after long idle period.

    After writing to MEAS_MODE to configure the sensor in mode

    1-4, run CCS811 for 20 minutes, before accurate readings are

    generated.

    Ich habe mir jetzt mal so ein Teil zum Testen bestellt.

    Super! Vielen Dank für den Haufen Arbeit. :thumbup::danke_ATDE:Das ist also der Adapter für TiNo Version 1.01.

    Eine Version 2.0 ist in Vorbereitung mit einer Reihe von Verbesserungen und Ergänzungen. Dabei wollte ich das Interface an das Protokoll vom TinyRx4 anpassen, weil es mir insgesamt besser für zukünftige Erweiterungen gerüstet erscheint.

    die Platine mit Klarlack, Expoxidharz oder PlastiDip versiegeln.

    bloss nicht! HF Komponenten reagieren extrem empfindlich auf sowas. Du musst schauen dass das Gehäuse einigermassen dicht ist, also das ganze Gehäuse in PlastiDip tauchen müsste gehen.

    Ich weiss es auch nicht viel besser, ich mache halt ins Gehäuse ein 5mm grosses Loch und klebe den Filter dahinter. Dass der TiNo trozdem vor Regen und Schnee einigermassen geschützt aufgestellt werden sollte versteht sich von selbst.

    Wenn du einen wasserdichten Temperatursensor brauchst, da gibts diese Dallas DS18B20 Sensoren die versiegelt sind. So einer baumelt bei mir im Teich seit einer Ewigkeit. Die Elektronik dann in ein wasserdichtes Gehäuse ausserhalb.

    so wie es aussieht, ist es aber sogar noch schlimmer geworden:

    sieht fast so aus als würdest du dir den HF Dreck jetzt übers Kabel einschleppen.



    Leider hab ich den Sender schon mit Silikon verlebt und in den Garten verfrachtet.

    Du hast aber schon daran gedacht in das Gehäuse ein Loch zu bohren damit die Luft an den HTU21D ran kann? Und du hast auch eine Filterkappe über den Sensor gesteckt, weil wenn der nass wird, kanns schon mal sein dass er Unsinn misst.


    Ich denke z.Z darüber nach wie man die Konfiguration OTA (over-the-air) machen kann, damit wird vieles einfacher. Dazu muss man am Gateway Daten bereit stellen, und wenn der TiNo einen ACK verlangt die Daten schicken.

    Ja, das ist logisch, denn das Tool setzt einen Puls am DTR Pin voraus. Ich arbeite immer mit FTDI Adaptern, da wird der Puls automatisch beim Oeffnen des seriellen Ports ausgeloest.

    So, wenn du keinen FTDI Adapter hast und so den Empfänger an einen USB Port des Raspberry hängen kannst, musst du den Empfänger NACH dem Start des Tools zurücksetzen. Dies geht mit einem Jumperkabel, indem du Pins 6 (Masse) und Pin 5(Reset) des ISP Adapters kurz verbindest und wieder oeffnest.

    Dann sollte es gehen.

    Im Foto ist die Brücke schwarz eingezeichnet, nicht vergessen sie wieder zu oeffnen, sonst arbeitet der Prozessor nicht.

    Eventuell geht es auch indem du die VCC kurz wegnimmst und den TiNo so neu startest. Das ist dann wahrscheinlich einfacher.

    der Receiver sollte sich dann melden mit calibration mode.. Danach pwd eingeben. Das ist eine Abkürzung um zu vermeiden dass man immer wieder das Passwort eingeben muss. Auch hier gibt es viel Raum für Verbesserungen.


    Turorial für das Tool ist in der Dokumentation auf meinem Github repository. Es ist, ehrlich gesagt, gewoehnungsbedürftig. Da arbeite ich noch dran.

    Es war mal mein Job genau solche Dinge zu automatisieren.


    Um die Frequenz anzupassen muss ich beide Sketche ändern? Sender und Empfänger, oder?

    ja klar! Am Sender 4800 Baud, am Empfänger 38400 Baud, geht aber nur mit dem Tool tinocal.py (Linux) bzw. tinocal_v007.py (Windows). Ist in meinem Github Repository.


    Aber am Kabel bin ich schon dran. Hab hier ein dreiadriges Mikrofonkabel mit Schirmung gefunden, müsste doch gehen wenn ich RX/TX//VCC darüber laufen lasse? Oder die Stromversorgung lieber getrennt lassen?

    Ich verwende Ethernet CAT6 Kabel, für jede Leitung RX,TX, VC ein Päärchen verdrillte Leitungen, eine Leitung jeweils an Masse.

    Mikrophonkabel geht wahrscheinlich auch, aber das Wichtigste ist die räumliche Trennung zwischen Pi und Empfänger!

    Hallo L.E.D.

    für meinen Geschmack hast du zu viele Fehltriggerungen, ca. 2 pro Minute. Versuche doch mal den Empfänger weiter weg von allem was Strahlung abgeben kann aufzustellen, also: mindestens 30cm vom Raspberry Pi, mindestens 50cm von jeder Sorte von LED Bildschirm, 1m vom Ferseher und 1m von Powerline Geräten. Auch jede Form von Schaltnetzteilen kann strahlen, manche mehr, manche weniger. Ich hatte anfangs auf 868.00 MHz gearbeitet, aber im Spektrum Analyzer habe ich dann gesehen was da alles los ist. Ich bin auf 865.00 MHz ausgewichen, da ist es (bei m ir zuhause) wesentlich ruhiger.

    Und das wichtigste fehlt auch noch, ein fancy Adapter-Icon.

    Ich mach mich dran, ich habe eine Idee im Kopf.

    Da aber diese Daten über den Empfänger bereits aufbereitet werden können und dessen Spannungsversorgung und Kommunikationsschnittelle auf kurze Distanz fest mit dem Raspi verkabelt sind, könnte man auf der 'letzten Meile' vermutlich auf ein kompliziertes Protokoll verzichten.

    Das ist sicherlich richtig, mit gewissen Grenzen. Das serielle Protokoll ist jetzt 38400 Bd, was nicht gerade rasend schnell ist. Das kann man mit einem 8MHz auf 57600 Bd aufmotzen. Es ist deshalb so wichtig weil die Ankunft eines Pakets so schnell wie moeglich abgearbeitet werden muss damit ein zweites das unmittelbar darauf folgt ebenfalls korrekt empfangen werden kann. Das heisst es sollte nicht eine Ewigkeit dauern die Daten übers serielle Interface zu bekommen. Auf ein paar mehr oder weniger Bytes kommt es aber nicht an.


    Dafür wäre das TinyRX4-Protokoll oder eine Weiterentwicklung davon, auch hinsichtlich der Erweiterbarkeit, sicherlich gut geeignet.

    denke ich auch.


    Die Frage ist jedoch, wie viel Anwender arbeiten bereits mit dem jetzigen Protokoll

    nicht so viele, wir sind noch in der Anfangsphase.


    Gibt es bereits Programme, die auf die Daten in jetziger Form angewiesen sind und lassen sich diese unproblematisch anpassen?

    ja und ja. Also meine Python Skripte halt. Habe ich aber noch nicht oeffentlich gemacht, muss ich erst ausmisten.


    Ist eine Funktionserweiterung mit dem jetzigen Protokoll ohne Aufwand möglich oder muss man dann sowieso die externen Anwendungen anpassen?

    Eine Funktionsanpassung ist leicht moeglich, aber mal ehrlich: das existierende Protokoll ist nicht in sich konsequent oder konsistent, da ist viel Beliebigkeit drin. Ich habe wirklich nichts dagegen sich eng am TinyRX4 zu orientieren.