Beiträge von topsurfer

    Hi,
    interessantes Thema, so was will ich gerade auch realisieren, um auch unabhängig von der Hausautomation auf einem Raspi die Wetterdaten der Netatmo abfragen zu können.

    Netatmo hat aber wohl da vor kurzem die Sicherheit erhöht, so dass für diese Abfragen nach meinem Verständnis Client-ID und Client-Secret mitgegeben werden müssen (kein User/Passwort ...).

    Kennt da jemand ein Script, welches entsprechend (schon) angepasst ist?

    (Oder liege ich falsch und das von Tell verlinkte Script (https://github.com/michaelmikl…/netatmo_getmeasurecsv.sh) immer noch funktionieren?)

    Klar ;)

    Hintergrund ist, das dr raspi im Keller ist und ich gerne "remote" ein anderes OS booten will ...

    Oder ist das wirklich nicht zu empfehlen?

    Habe mal testweise Berryboot installiert, geht, aber dieses erstellt ja keine einzelne Partitionen auf der SSD pro OS, sondern "handelt" das alles in einer großen Partition (plus die kleine boot) ab ... zum reinkopieren eines OS (mittels dd) ist das ja so nicht zu gebrauchen :(

    Hi,
    ich versuche auf meinem Raspberry Pi 4 ein Dualboot einzurichten, default soll das OpenHabian gebootet werden, alternativ ein Raspbian.

    Habe beide nacheinander auf meine SSD installiert und von den beiden dann jeweils die zwei erstellten Partitionen (256MB (/boot) und 10GB (OS)) mittels dd gesichert.

    Wollte jetzt "einfach" dann die /boot (in 1.Partition) entsprechend austauschen und in der fstab die Partition für das Raspbian von vorher 2 auf 3 ändern, aber das Raspbian wird nicht gebootet.
    Partitionen der SSD sehen so aus (mit gparted entsprechend erstellt und mit dd gearbeitet):
    - 1. Partition=256MB : boot
    - 2. Partition=10GB : OpenHabian
    - 3. Partition=10GB : Raspbian

    Sollte das so prinzipiell funktionieren?
    Oder geht das nicht, muss ich noch mehr anpassen?

    Oder wie läßt sich ein einfaches Dualboot auf dem Raspberry umsetzen?
    Habe Noobs gesehen, aber nicht weiter angeschaut.

    Pi-boot-switch.sh hab ich auch gesehen, bietet aber zuviel Optionen.

    Danke für Tipps & Ideen!
    Martin

    Mir fehlt leider das tiefere Verständnis für die "Bitschieberei" und auch für Python ansich ...

    Das Ausgangsscript von #1 läuft ja jetzt stabil, nachdem die kleinen Änderungen an der Schaltung (Elko, Kondensatoren und Channels auf Ground) ausgeführt wurden.
    Letztlich möchte ich ja "nur" 3 Spannungen am Wohnwagen paar Tage lang protokollieren, und dafür werde und kann ich mich nicht extra in den MCP3008 und Python tiefer einarbeiten.

    Danke euch für eure Hilfe!!

    Ich habe es noch überarbeiten müssen. Das dauerte etwas, bis ich die Fehler gefunden habe. Ich habe in der Datei ganz oben noch ein Shebang für Python3 eingefügt.

    Ich bin mir nicht ganz schlüssig, wann Daten geschrieben und gelesen werden soll in Bezug auf die steigende bzw. fallende Flanke.

    Hi, gerade diese Version mal probiert,
    beim Aufruf erscheint einmal die "190", danach nur noch "0" ...
    190 ist auch etwas wenig, entspricht ca. 3.8V (anstatt 7.6V)

    Falls du noch weiter probieren willst und den Fehler versuchen willst zu finden, gerne. Ich teste es dann gerne!

    jar: Ich habs ja verstanden, nur bisher hatte ich eher an Schaltungen einen Siebkondensator an +/- angeschlossen (wie auch in den Schaltungen vorgegeben). Die gibt es ja auch....

    OK, ich dachte der Kondensator zwischen Plus und Minus (nah am MCP) sollte eher als Sieb/Stützkondensator des MCP dienen, du meinst also "raus" mit dem Elko und einen 100nF zwischen Vcc und Gnd ?

    Hi,
    danke für die weiteren Tipps und Infos, aber was #35 mir sagen (oder zeigen) soll weiß ich immer noch nicht ;)

    Habe jetzt Ch 3 bis 7 auf Masse gelegt und einen 47uF zwischen Vcc und Ground gelegt, (*)
    zumindest die letzten 13h keine einzige Fehlmessung erhalten!
    Werte größer 1023 kann ich ignorieren und wegfiltern, ist klar, das mache ich dann auch. Mir kam es nur falsch vor, das diese überhaupt entstehen können.
    Und das am (unbelegten) Ch0, der über 10k auf Masse gezogen ist, plötzlich digitalwerte von 60, 72, oder auch 320 erfasst werden, war ja merkwürdig.
    Aber evtl. ist das durch diese Maßnahme (*) ja dann damit vorbei.

    bombom: Wie gesagt, würde dein Script gerne auch mal laufen lassen, aktuell liefert es aber nur "0" zurück.

    topsurfer nimm das Skript aus Deiner Anleitung (von Erik Bartmann), das kann ich lesen.

    • 5 Bit Kommando an Din (=11bbb, bbb ist die binäre Kanalnummer 000..111) und dann
    • 11 Bit Daten von Dout (=0bb.bbbb.bbbb, b=[0|1], die Punkte sind nur zur Lesbarkeit)

    sorry bombom

    Du meinst wohl hier im Teil des Scripts, aber was soll ich da wie austauschen, erweitern ? Sorry ...

    Wenn du willst dann kannst du versuchen ob mit dem Code weniger Fehler kommen.

    Gerade mal den Code probiert, scheinst ja die gleichen Pins/GPIO's vom Raspi zu nutzen wie in dem Programm welches ich verlinkt hatte => Verkabelung bleibt also gleich.
    Aber das Script liefert immer nur "0" zurück (genutzter Ch1 sollte ja ca. 370 liefern).
    Ist da noch ein Fehler drin?

    PS: Hier fehlt am Zeilenende der ":" ;)

    Code
    def get_ADC_Data (Channel)

    OK, ist nur leicht abgeändert wie im ersten Thread verlinkt, habe auch dessen Bild Schaltung als Ausgangsbasis genommen und verwendet ....

    - Kein Poti, stattdessen ein Spannungsteiler: Aus 47K und 10K (an Masse) (genaugenommen keine 10K, sondern 9.09K (100k parallel zu 10k))
    - 10nF (oder 100nF?) Kondenastor an den drei genutzten Channels gegen Masse

    - 3 Channels beschaltet (also 3 Spannungsteiler, 3 10nF Kondensatoren verbaut)

    Kabellänge vom Raspi zur Schaltung:15cm

    Hinweis: Elektrisch "passt" die Schaltung ja, es werden ja zu 99% korrekte Werte geliefert an allen 3 Channels! Wenn eine Verbindung schlecht oder falsch wäre, wäre der Fehler ja dauerhaft.
    Und ja, die Leitungsführung und die Umsetzung könnte schöner und besser sein. Aber dafür das ich das so gut wie nie mache und dies nicht mein Fachgebiet ist ....

    Du liest doch die digitalen Werte aus. Diese werden doch erst in deinem Programm zu den Spannungswerten umgerechnet.

    Ich weiss nun nicht wie du die Spannungswerte sicherst. Mach eine zweite Datei/Datenbank auf und speichere dort.

    OK, ich dachte du meinst Werte vom Chip, was mit 0100101001 ...

    Diese digitalen Werte hatte ich schon mal mitprotokolliert, die passen zu den dann ermittlten Spannungswerten ... also kein Formel-Fehler ...
    Siehe:
    ...

    13.11.2019 16:58:30 0.00 7.60 2.51

    0.000000 382.000000 126.000000

    13.11.2019 16:58:30 0.00 7.60 0.00

    0.000000 382.000000 0.000000

    13.11.2019 17:08:23 0.00 7.60 1.25

    0.000000 382.000000 63.000000

    13.11.2019 17:08:24 0.00 7.60 0.00

    0.000000 382.000000 0.000000

    13.11.2019 17:08:52 0.00 7.60 33.12

    0.000000 382.000000 1664.000000

    ...

    Die Undervoltage-Warning sehe ich nur in der GUI/Console, oder? In keinem Logfile?
    Aktuell gehe ich nur per ssh auf den Raspi, GUI ist keine gestarted.

    Am SPI-Takt habe ich nichts geändert, nur über Raspi-config eingeschaltet.

    Wie kann ich die digitalen Werte denn protokolieren?


    kle, danke:
    Einen 1 uF kann ich mal anschliessen, soll einfach an die Spanungsversorgung vom MCP angeschlossen werden ... möglichst nah an die Pins vom MCP. Korrekt?

    Was echt merkwürdig ist, warum stundenlang "Ruhe" herrscht, und dann auf einmal (hier aif CH0) Fehlmessunegn erfasts werden...
    Ab 4:00:46 Uhr herrscht 6 Stunden Ruhe auf CH0, zuvor ... siehe Spoiler... und es wurde da nix gemacht (Föhn, Erschütterungen, Telefon, ...), haben alle geschlafen ;)
    Irgendwelche "hohen" Bits scheinen da zu hohe Werte zu verursachen ....

    Spoiler anzeigen

    date - time - ch0 - ch1 - ch2

    14.11.2019 03:42:16 18.47 7.38 0.00

    14.11.2019 03:42:17 0.00 7.38 0.00

    14.11.2019 03:42:19 36.94 7.38 0.00

    14.11.2019 03:42:20 0.00 7.38 0.00

    14.11.2019 03:42:22 25.48 7.38 0.00

    14.11.2019 03:42:23 0.00 7.38 0.00

    14.11.2019 03:59:27 0.00 7.40 0.00

    14.11.2019 03:59:28 0.00 7.38 0.00

    14.11.2019 04:00:35 33.12 7.38 0.00

    14.11.2019 04:00:36 0.00 7.38 0.00

    14.11.2019 04:00:37 16.44 7.38 0.00

    14.11.2019 04:00:38 0.00 7.38 0.00

    14.11.2019 04:00:43 25.48 7.38 0.00

    14.11.2019 04:00:44 0.00 7.38 0.00

    14.11.2019 04:00:46 25.48 7.38 0.00

    14.11.2019 04:00:47 0.00 7.38 0.00

    14.11.2019 04:09:06 0.00 7.36 0.00

    14.11.2019 08:46:21 0.00 7.32 0.00

    14.11.2019 09:28:31 0.00 7.28 0.00

    14.11.2019 10:01:20 0.00 7.24 0.00

    14.11.2019 10:03:06 0.00 7.20 0.00



    Inwieweit das Python Script "gut" ist und ob die Funktion von /cs "gut" im Script abgebildet ich, kann ich leider nichts zu sagen.
    Bin kein spezialist für Digitaltechnik, auch nicht für Python.

    Ja, die Batterie hängt an CH1,
    Ch0 bis 2 haben einen Pulldown zu Masse hin.

    Dann werde ich die ungenützten Channels auch mal (sicherheitshalber) über Pulldowns an Masse legen ...

    Was aber merkwürdig ist, am CH1 hängt ja über ein Spannungsteiler die (schwache) 9V Batterie, wie kann so eine Fehlmessung zu stande kommen?
    Digitalwert (exact) 2000 <=> 39.81 V !!??

    Oder muss man damit leben? Irgendwelche Störungen an Vcc, am 230V, Spannungsspitze, Funkstörung vom DECT Telefon, ... ?

    - Date - - Time - - Ch0 - - Ch1- - Ch2 -

    13.11.2019 14:36:14 0.00 7.60 0.00

    13.11.2019 14:36:23 0.00 39.81 0.00

    13.11.2019 14:36:23 0.00 7.60 0.00

    Auch merkwürdig, 0V / 0 digits , obwohl ja eine Batterie dranhängt:

    13.11.2019 14:55:13 0.00 7.60 0.00

    13.11.2019 15:00:55 0.00 0.00 0.00

    13.11.2019 15:00:56 0.00 7.60 0.00

    Stimmt, ich meine den digitalen Wert, den der MCP ermiitel hat und an den Raspi liefert.

    Die Bauteile sind auf einer Platine verlötet, verwende Widerstande (kein Poti).
    Die Spannung die ich testweise messe ist eine teilentleerte 9V Blockbatterie, das ganze liegt auf dem Schreibtisch und sollte keinerlei Störungen unterliegen.

    Hab weder am Code, am Aufbau oder der Position auf dem Schreibtisch was geändert und die ganze Nacht keine einzige Fehlmessung protokolliert, merkwürdig!

    So sah es gestern aus (ich schreibe die Werte nur in die Datei wenn sich mindestens ein (Spannungs-)Wert geändert hat!):

    Spoiler anzeigen

    ...
    12.11.2019 17:43:00 0.00 7.64 0.00

    12.11.2019 17:43:01 0.00 7.62 0.00

    12.11.2019 17:44:53 0.00 7.62 10.13

    12.11.2019 17:44:54 0.00 7.62 0.00

    12.11.2019 17:45:00 0.00 7.64 0.00

    ...

    12.11.2019 17:48:54 0.00 7.64 0.00

    12.11.2019 17:48:55 0.00 7.62 0.00

    12.11.2019 17:50:03 0.00 36.94 0.00

    12.11.2019 17:50:04 0.00 7.62 0.00

    12.11.2019 17:50:10 0.00 7.64 0.00

    ...

    12.11.2019 18:21:43 0.00 7.62 0.00

    12.11.2019 18:23:31 0.00 7.62 36.94

    12.11.2019 18:23:32 0.00 7.62 0.00

    ...

    12.11.2019 18:27:29 0.00 7.62 0.00

    12.11.2019 18:36:47 0.00 7.62 38.85

    12.11.2019 18:36:48 0.00 7.62 0.00

    ...

    12.11.2019 19:02:50 0.00 7.62 0.00

    12.11.2019 19:05:29 0.00 25.48 0.00

    12.11.2019 19:05:30 0.00 7.62 0.00

    ...

    12.11.2019 19:06:31 0.00 7.62 0.00

    12.11.2019 19:08:42 0.00 7.62 38.85

    12.11.2019 19:08:43 0.00 7.62 0.00

    ...

    12.11.2019 19:08:42 0.00 7.62 38.85

    12.11.2019 19:08:43 0.00 7.62 0.00


    Oder sind diese "Störungen" doch verursacht durch Störungen auf dem 230V Netz, der Raspi und somit auch der MCP wird ja darüber versorgt (Raspi hängt an USB Buchse vom PC, dieser an 230V)

    Update:
    Eben doch wieder paar Fehlmessungen:
    13.11.2019 12:37:38 0.00 7.60 20.14

    ...

    13.11.2019 13:11:37 25.48 7.60 0.00


    Kann es daran liegen das die nicht genutzten Channels (3 bis 7) "offen" sind und kein Pulldown gegen Masse haben? Das da was "reinfunkt" ?

    Alles klar, k.P.!
    Ich hatte versucht wirklich viele bzw. alle notwendigen Infos mitzuliefern ...

    Das Python-Script habe ich auf drei Eingänge erweitert, alle drei Eingänge funktionieren soweit (und sind mittels Pulldown Widerstände auf Masse gezogen).
    Darüber hinaus verwerfe ich alle Messungen (Zählungen) unter 40 Impulsen (<0,7V)

    Jetzt habe ich das Script mal 2h laufen lassen, und sehe auf zwei der drei Eingängen (mal auf Ch1, mal auf Ch2) alle etwa 30 Minuten (mal 15, mal 45 Minuten) unsinnige Werte:
    1952 Impulse, 1856 Impulse, ...
    Die anderen Messwerte dazwischen sind exakt und haben keine "sprünge".

    Woher können diese Fehler kommen, der MCP3008 sollte doch höchstens 1023 zurückliefern können?
    Timing-Probleme? Starke Störimpulse? Prinzipiell (meistens) stimmen ja die Werte und Funktion !?

    In der Funktion GetAnalogData habe ich einen Sleep von 0.1s (wird bei 3 Channels ja 4x aufgerufen) eingebaut, zusätzlich in der while/endlos -Schleife 0.7s. Somit ermittle ich (ca.) jede Sekunde einen Messwert.
    Ich habe die sleeps jetzt mal erhöht und beobachte mal ....