Beiträge von RTFM

    Das Problem ist, dass viele Anfänger in der Meisterklasse beginnen wollen.


    Da beide Distributionen mit dem Linux-Kernel betrieben werden, ist es einem, Könner wahrscheinlich möglich beide Distris auf einem System zu vereinen. Daneben kann ein System auch in einer VM (virtuelle Maschine) des anderen laufen.


    Der Pi ist ein Lern- und Bastelgerät und nicht dafür gedacht, ein paar Scripts ais dem Netz zu fischen und damit ein vermeintlich lauffähiges Programm zu erstellen. Da musst Du Dich vorher mit den Grundzügen von Linux, seinen Standardprogrammen, den Multiuser-Rechten und den Eigenheiten von Stromversotging und MMC usw. vertraut machen.


    Zum Überwachen eines Koiteiches btauchst Du nicht unbedingt Raspberry Matic. Das ist für die paar Aktoren und Sensoren wahrscheinlich oversized.



    Servus !

    Und was den Alarmserver angeht, dass ist NUR eine Nachricht, die die CAM via URL an eine beliebige IP:80 sendet. Der empfangende Host muss eben nur etwas damit anfangen können.

    Dann ist die Alarmnachricht im Localnet mit Wireshark o.Ä. ja auslesbar, und z.B. mit Python handlebar.


    Meine Vermutung war von "Kundenbindung" geprägt.

    Aber dann dürfte das Rad, wonach der TO sucht, bei den IoT Freaks auch schon erfunden worden sein.


    Servus !

    So wie ich das bei Instar gelesen habe, löst der Alarmserver eine Aufzeichnung für 15 Sekunden samt 3, oder 5 Sekunden vor dem Alarmsignal, aus. Das Signal zur Auslösung einer Sirene ist eine reine Softwarelösung, vermutlich über den (kostenpflichtigen) Instar-Server. Der ist aber https-verschlüsselt.


    Das Herausfinden der Alarmsequenz samt Umleiten auf den Pi (tzm Starten des Live Bildes, mit welchem Programm auch immer) ist daher eine ziemliche Herausfordering, wenn man sich die Instar-Serverkosten ersparen will.


    Eigentlich sollte die Alarmprozedur im mitgelieferten Handbuch beschrieben sein. Doe Alarmaislösung über den instar Server ist meine persönliche Vermutung.



    Servus !

    Ich würde ja auch auf der 230 V Seite den Schaltzustand detektieren. Mit einem AC-Optokoppler, oder einem Hall Sensor. Extrembastler haben dazu auch schon ein Kompassmodul missbraucht.


    Aber Du lehnst das strikte ab.


    Beim ersten (unfreiwikkigen) Reboot kommt Dein Impulszählwerk spätestens aus dem Takt.



    Servus !

    Du hast u.A. die Möglichkeit einen --dry-run auf Dein upgrade auszuführen. Da werden alle Änderungen nur angezeigt, aber nicht durchgeführt.

    Servus !

    Nur bei den Festplatten und sonstigen Speichersystemen war das immer schon so. Schon die erste Festplatte des IBM PC hatte nur 9,1 MB und wirde als 10 MB verkauft. Bei den optischen Speichern (CD, DVD, Blue-R) muss man sich auch das i bei der Speichergrösse dazudenken, glaube ich.



    Servus !

    Du gehst an Deine Idee vllt nicht ganz richtig ran. Du solltest mehrere Möglichkeiten abchecken und dann nur das auswählen, was Du selber realisieren kannst.


    Beim Pi und anderen Elektronikbasteleien fängt man meistens mit dem Schalten einer LED an und nicht mit dem Abschreiben einer Masterarbeit, ohne den Inhalt zu verstehen.


    Ob ein Drucksensor die alleinige, richtige Wahl ist, kann ich auch nicht sagen, da nicht bekannt ist, ob der überhaupt den Maximalwert im richtigen Moment misst, und der A/D Wandler den auch rechtzeitig in einen Digitalwert umwandelt.


    Da wäre eine Zeitmessung einfacher. Je kürzer die Zeit zwischen Abschlag und Aufprall, desto mehr Puntch.


    Servus !

    Als weiteres Missverständnis kommt dazu, dass von der 9,1 TiB HD rd. 5 - 10 % Plattenkapazität für die Filesystem-Metadaten verwendet werden, und weitere 5 % ausschliesslich für den User root reserviert wurden, wenn mit den voreingestellten default-Optionen das EXT4 Filesystem erstellt wurde.


    Servus !

    Die Störmöglichkeiten am 1-wire Bus sind vielfältig und zeigen sich v.A. beim (Master) search, bei dem alle Clients gemeinsam vom Master angesprochen werden. Da kann der letzte Client am Bus schon mal auf der Strecke bleiben und keine gültige ID mehr an den Master mehr senden. Dann bleibt er bis zum nächsten search, oder reset ausgeschlossen.


    In MAXIM APPNote 187 und Tutorial148 findest Du Hinweise zur allfälligen Bus-Optimierung.

    https://www.maximintegrated.co…pp-notes/index.mvp/id/148

    https://www.maximintegrated.co…pp-notes/index.mvp/id/187


    Servus !

    Zunächst nicht mehr rw mounten. Weder am pi, noch am Win-PC.


    Dann ziehst Du eine Image-Kopie (z.B. mit Linux dd) der HD auf eine HD, die mehr als 250 GB freien Speicherplatz hat und checkst die Prüfsummen auf Identität.


    Danach schaust Du mit Linux lsblk, chkdsk, u.Ä. nach, was alles in der Partitionstabelle geändert wurde.


    Mit der Sicherheitskopie des GPT-Headers stellst Du die ursprüngliche Partitionierung wieder her.

    Falls noch DOS-MBR verwendet wurde gibt es davon keine Kopie. Dann musst Du "raten" und die Partition Nr 1 mit 2048 1024 Sektorbeginn vorerst erstellen.


    Mit dem alternativen Superblock des zerstörten Filesystems versuchst Du das Filesystem wiederherzustellen.



    Servus !

    Da Du noch immer Dein System dem Programm anpassen willst, und nicht umgekehrt, versuche in den Einstellungen "Benachrichtigungen" auszuschalten. Möglicherweise ist die Nachricht "Stick ohne Auswerfen entfernt" weg und der Focus bleibt auf dem Xterminal dessen xkbd (auch) mit dem Kartenleser verbunden ist.


    Servus !

    Du hast von Sektor 1 bis zum letzten Sektor der Img Datei die HD überschrieben und damit auch die Metadaten der Platte (GPT, Partitionstabelle) mit den Metadaten der SD (DOS-MBR Partitionstabelle) ersetzt. Der DOS Master Boot Record (MBR) ist nur für Festplatten bis rd. 500 GB geeignet, deshalb musst Du den ursprünglichen GPT wiederherstellen. Zum Glück befindet sich in den letzten Sektoren, also am Plattenende eine Sicherheitskopie davon.


    Wenn die ursprünglichen Partitionsgrenzen mit einem rekonstruierten GPT wiederhergestellt sind, kannst Du versuchen mit der Superblock-Kopie des Filesystems dieses zum Grossteil wiederherzustellen. Unter Windows hat die NTFS Superblock-Kopie allerdings eine andere Bezeichnung, da müsstest Du Dich in den Programm Dokumentationen selbst schlau machen, oder in den alten Thread (von KLE ?) hier rein schauen. Dort wurde meiner Erinnerung nach, der DOS-MBR gleich zweimal auf zwei verschieden grosse HDs "verteilt".


    Wenn das auch nicht geht, kannst Du mit den bekannten Forensik Tools aufgrund der Bitmuster auf der Platte eine Rekonstruktion versuchen. Das ist aber mehr für Bild und Videodaten geeignet. Es entstehen auch jede Menge Filefragmente, die dann händisch zusammengefügt werden müssen.


    Vorraussetzung für eine Solche Reparatur am offenen Herzen ist aber das Lesen und Verstehen der zugehörigen Dokumentation. Eine Programmrückfrage "Continue/Abort ?" darf nicht nach dem Trial & Error Printip beantwortet werden.



    Servus !


    PS Wie ich gerade sehe, hast Du die letzte Option schon gezogen.

    Eigentlich sollte in Impress ein Shortcut für das Weiterschalten vorhanden, oder definierbar sein.


    Dann sendest Du bei Auslösen des Tasters den Textsring für den Shortcut an das zuständige Input Device.


    Servus !

    Eine andere Möglichkeit wäre, den Bildschirminhalt des Pi (=TV) als LiveStream an den PC (Unicast), oder einer Multicast-Gruppe zu senden.


    Siehe die drei Dokumentationslinks von https://www.videolan.org/support/#documentation


    Ein Programm, dass das auf beiden Seiten kann, ist VLC. Auf der grossen Raspian-Distri sogar schon vorinstalliert.


    Mit der Hardware des Pi stösst Du aber schnell an die Grenzen für Video am Pi, insbesondere wegen seines gemeinsamen USB/Ethernet Controllers. Dafür nimmt man eher einen (ausrangierten) PC (mit GraKA, ATA/SATA HD) mit irgendeiner Linux Distri.


    Servus !