Entwicklung: Temperatur Funk Sensor

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Danke für das log.

    Scheinen alles Fehltriggerungen des Empfängers zu sein.

    Zu mindestens sehe ich da kein Fehlverhalten vom Adapter.

    Zu deiner Frage nach dem TinyRX4 Protokoll:

    Der TinyRX4 Empfänger gibt auf der Seriellen Schnittstelle die Werte wie folgt aus:

    Code
    13 v=3844&t=2630&h=5260
    |||||||||||||||||||||||
    |||||||||||||||||++++++---- Luftfeuchte / 100 (h=humidity)
    ||||||||||||||||+---------- Trennzeichen für den nächsten Wert
    ||||||||||++++++----------- Temperatur / 100 (t=temperatur)
    |||||||||+----------------- Trennzeichen für den nächsten Wert
    |||++++++------------------ Batteriespannung / 1000 (v=voltage)
    ||+------------------------ Trennzeichen zu den Datenwerten
    ++------------------------- Node Id

    Diese Nachricht ist sehr gut lesbar und lässt sich theoretisch unbegrenzt erweitern indem man einfach den nächsten Wert mit seiner eigenen Variable und dem Trennzeichen '&' anhängt.

    Jedoch ist diese Nachricht relativ lang. Der TinyRX4 ist durch den verbauten Attiny84 beschränkt in seiner Sensoranzahl und wird wohl meist nur für 3 bis max. 5 Sensorwerten benutzt.

    Werte wie RSSI, Link Quality, Frequenzversatz, Message Counter und die Interrupts gibt es beim TinyRX4 nicht, daher hält sich die Gesamtlänge der Nachricht in Grenzen und das ganze ist selbst bei der als Standard eingestellten Übertragungsrate von 9600 Baud kein Problem.

    Ich hatte zu mindestens mit meinen 10 Sendern die im 3 Minutentakt ihre Nachricht beim Empfänger abliefern bisher keine grösseren Probleme.

    Wird die Nachricht jedoch wesentlich länger und man hat viele Nodes, die zufällig gleichzeitig Senden kann es theoretisch sein, das der Empfänger eine Nachricht nicht Empfängt, weil er noch damit beschäftigt ist die letzte Nachricht auf die Serielle Schnittstelle zu schieben.

    Das bei 57600 Baud auf der kurzen Strecken zwischen Empfänger und Raspi Probleme auftauchen kann ich mir nicht vorstellen, aber wirklich beurteilen kann ich das auch nicht.

    Einmal editiert, zuletzt von bowao (29. Juli 2019 um 23:18)

  • 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.

  • Spektrum Analyzer habe ich leider keinen :)
    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?

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

  • 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!

  • 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.

    OK, der Empfänger hängt ja schon am PI. Also PySerial installiert und das tinocal.py Skript gestartet. Und dann?

    ready.

    nach einiger Zeit kommt dann:

    --> NodeId,236,s=-106.00,data:FAIL;7;236;0xA5;unknown format!;,FEI=-186,T=31,biterrors=0

    also ist die Verbindung korrekt.

    help listet zwar was auf, aber damit kann ich nicht so viel anfangen und "c" und "ls" und so scheinen auch nicht zu funktionieren. Dafür brauche ich wohl ein Tutorial ;)

    Einmal editiert, zuletzt von L.E.D. (30. Juli 2019 um 10:47)

  • 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.

  • OK, Anleitung hab ich gefunden. Werde ich heute Abend oder morgen testen.

    Der Empfänger hängt jetzt an einem geschirmten 5m Kabel und liegt mitten in einem Raum ohne strahlende Technik. So wie es aussieht, ist es aber sogar noch schlimmer geworden:

    Spoiler anzeigen

    Jetzt muss ich mich Mal nach einer USB Verlängerung umsehen und / oder die Frequenz ändern. Leider hab ich den Sender schon mit Silikon verlebt und in den Garten verfrachtet.

    Im nächsten Leben kaufe ich einfach die Xiaomi Smart Temperatursensoren für 8,-€ pro Stück und gut ;)

  • 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.

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

    Schlecht geschirmt? Morgen verlänger ich die USB Leitung und nehme ein kurzes CAT5 Kabel für die Verbindung zum Empfänger.

    Du hast aber schon daran gedacht in das Gehäuse ein Loch zu bohren damit die Luft an den HTU21D ran kann?

    Dann hätte ich mir das Silikon sparen können... die Luftfeuchtigkeit brauch ich da erst Mal nicht. Dafür hab ich noch einen DHT22 am Feinstaubsensor. Aber der brauch Strom und die TiNos sollen etwas weiter weg in den "Dreck" :)

    An Filterkappe hatte ich auch schon gedacht und dann ggf. die Platine mit Klarlack, Expoxidharz oder PlastiDip versiegeln. Aber die Knopfzelle und deren Kontakte müssen ja frei bleiben und der ISP und der FTDI am besten auch. Bin noch unschlüssig wie die beste Lösung aussieht.

  • 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, hier noch Mal ein Feedback von mir.

    Wenn es am Adapter liegt könnte ich darin evtl. etwas erkennen.

    Wie es aussieht hatte ich noch ein kleines Problem mit der Stromversorgung des Raspberry Pi. Das Netzteil ist zwar sehr gut, aber irgendwie habe ich das Kabel wohl vertauscht. Habe zwei gleich kurze Kabel und eines davon liefert offensichtlich zu wenig Spannung für einen stabilen Betrieb. Kabel getauscht und jetzt läuft der Pi. Der Adapter zeigt ebenfalls keine Auffälligkeiten, trotz der immer noch recht häufigen Fehltriggerungen vom Empfänger.

    Ich warte auf eine USB Verlängerung die ich bestellt habe, hoffe dadurch wird es dann besser.

  • zwei gleich kurze Kabel und eines davon liefert offensichtlich zu wenig Spannung für einen stabilen Betrieb.

    sowas zu lesen tut weh... (U = R * I).

    Eine Spannungsquelle liefert eine konstante Spannung. Wird die garantierte Stromstärke überschritten, bricht die Spannung zusammen.

    Ein Kabel stellt einen mehr oder weniger großen Widerstand dar. Je dünner und/oder länger das Kabel ist, desto größer der Widerstand. Je mehr Strom durch ein Kabel fließt, desto wärmer wird es.

    Schönen Gruß, kle

  • sowas zu lesen tut weh... (U = R * I).

    Muss nicht weh tun... der PI überwacht ja nur die Spannung und offensichtlich stimmt mit dem Kabel irgendwas nicht, so dass nicht die vollen 5V ankommen. Obwohl das Kabel nur 15cm lang ist. Da fließen aktuell nur 390mA drüber, sollte also auch ein Kabel mit großem Widerstand schaffen. An der Wärme lag es also nicht ;)

  • Die Probleme mit den Netzteilen hatte ich bei meinem ersten Raspi auch.

    Die meisten Netzteile leisten nicht das was sie versprechen, haben schlechte Stecker/Buchsen mit Übergangswiderständen oder das Kabel ist zu dünn und/oder hat schlechte Stecker usw.

    Es mag sicherlich auch gute Standard USB-Netzteile und Kabel geben, aber um dem Problem aus dem Weg zu gehen kaufe ich zu jedem Raspi nur noch das Original Netzteil (das mit der Himbeere).

    Damit läufts garantiert.

    Je nachdem was du mit dem Raspi noch so anstellen willst könnte das nächste Problem vermutlich die Lebenszeit der SD Karten sein.

    Ich hab am Anfang nicht darauf geachtet, das meine Experimente extrem viele Schreibzugriffe verursachten und hatte einmal im Jahr einen SD-Karten Ausfall.

    Seit dem versuche ich dies zu vermeiden.

    Zusätzlich nutze am Hausautomations-Raspi eine 2.5" Festplatte über einen USB-Hub mit gesonderter Stromversorgung.

    Dahin lagere ich die meisten Schreibzugriffe wie Logs und Trends aus.

    Vielleicht sind die SD-Karten mittlerweile robuster, aber man sollte trotzdem darauf achten, nicht jedes ankommende Bit direkt auf die SD-Karte zu schreiben.

  • Kann man dem Raspberry Pi auch einfach über die Steckerleist die 5V zuführen? Dann würde ich einen externen Spannungswandler direkt anschließen und auf 5,1V stellen.

    Das mit den SD Karten habe ich auch schon gelesen, bin mir aber nicht sicher wie ich die Schreibvorgänge genau kontrollieren kann. Für den iobroker hab ich redis installiert, sollte schon etwas bringen. Ansonsten wird als Alternative oft auf USB SSDs (SLC) hingewiesen. kostet dann aber natürlich auch ein paar Euro.

  • Hi,

    war kurz in einem anderen Projekt untergetaucht.

    Falls Interesse besteht einen BME280 I2C Feuchte, Luftdruck und Temperatur Sensor an einem TinyTX4 zu betreiben, ich hab da mal was vorbereitet:

    https://github.com/bowao/tinytx4_bme280


    Zurück zum TiNo:

    Also im Prinzip geht auch eine Einspeisung über GPIO, aber davon wird eigentlich abgeraten:

    https://www.raspberrypi.org/magpi/power-supply/

    Sonst irgendwelche neuen Erkenntnisse?

    Adapter-Logo?

    Sind die Datenpunkte im Adapter vollzählig und korrekt benannt?

    Lässt sich FEI eventuell für nicht HF-Spezialisten ausführlicher benennen?

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!