Loetkolben

Meine Anmerkungen/Fragen dazu vom dem was ich bisher verstanden habe. Wenn ein Bricklet im Stack getauscht wird muss dann wirklich die Software angepasst werden? 3 Mal tauschen bedeutet 6 mal patchen? Kann man die neuen Funktionsaufrufe gruppieren, wobei auch "Loecher" sein duerfen? Siehe "get_usb_voltage" 00-0f Spannungen 10-1f Wifi 20-2f RS485 30-3f Onboard LED Sind OO [Other Options] (2 bit) nicht ein wenig zu klein gedacht? Oder habe ich es nicht verstanden? So und nun mein groesstes anliegen. Kann man nicht anstelle der Bitfummelei einfach Bytes nehmen? Ja, als Hardware naher Mensch liebe ich es auch mit Bits auf die Beinchen vom Chip zu gehen, aber wenn man mit Software hantiert, dann muss man aus 5 true/false Werten erstmal umstaendlich ein Byte basteln. Spaetestens bei der Shell tut das weh! Mit einem "if true then x=\01 else x=\00" geht es viel leichter und es waere doch sicher vielen geholfen. Die 10 Byte mehr pro Paket sollten doch niemand stoeren. Ich muesstet dann nur so parsen: Entweder \00 = Funktion nicht gesetzt (0) und \01 = Funktion gesetzt (1) Rest wird ignoriet oder \00 = Funktion nicht gesetzt (0) und \01 bis \ff = Funktion gesetzt (1) Der Loetkolben

Hallo Nic, Koenntest du bitte "RaspPi" in "Raspberry Pi" aendern sonst findet das niemand ueber die Suchfunktion. Danke. Der Loetkolben

Hallo ArcaneDraconum, nichts fuer ungut, aber was bedeutet die "3.14" in der Ueberschrift? Ich vermute da was, aber selbst warte ich erst noch auf meinen Raspberry Pi und kann deshalb nur raten. BTW: Koenntest du anstelle von "Himbeere" besser "Raspberry Pi" in der Ueberschrift nutzen. Warum? Wenn man den Beitrag liest oder in der Forumsliste sieht, weiss jeder genau worum es geht. ABER wenn jemand die Suchfunktion anschmeisst wird er ggf. deinen Beitrag deshalb nicht finden. Vielleicht einfach nur nuechten so: "Raspberry Pi Firmware 3.14" Nicht huebsch oder witzig, aber praktisch. An dieser stelle danke fuer den Hinweis mit den Netzteilen. Der Loetkolben

Hallo photron, danke fuer die brickd Anpassungen! Scheint auch alles zu funktionieren. # /etc/init.d/brickd start Starting Brick Daemon: Already running according to /var/run/brickd.pid Der Loetkolben

Vorteil: Je weniger Adapterkrams um so robuster arbeitet das Gesamtensemble. Ausserdem muesste man noch die Kosten obendrauf rechnen. Weiterhin sei die Frage gestellt: Wer hat einen PoE Switch in dem Umfeld wo der Stack eingesetzt werden soll? Ich glaube kaum, dass jemand fuer den Tinkerforgestack den Switch tauscht. Da werden 95% der User die Adapter nutzen und wenn eben diese 95% der User das benoetigen koennte man es auch einbauen! Stellen wir mal die Frage so: Welche Spannungen/Normen werden denn ueber die RJ45 Buchse akzeptiert? Der Loetkolben.

Hallo batti, macht bitte wenigstens einen 5V Loetanschluss. Z.B: 2 Loetpunkte und darunter 2 Loecher um Stifte einzusetzen. Dann kann man auswaehlen ob man ein Kabel anloeten will oder ueber 2 Stifte die Spannung anlegen will. Ist denn wirklich keine Ecke mehr frei fuer einen, wenn auch ueberstehenden, Poweranschluss? Der Loetkolben

Raeusper, darf ich nochmals hierrauf verweisen: Ethernet mit PoE - Bitte auch 5Volt zulassen. Echtes normgerechtes PoE ist mit Sicherheit in Ordnung, aber dafuer muss teuere Technik mit auf das Brick zum aushandeln der Klasse und stabilisierung der Spannung. Billiges 5 Volt "PoE" per Drahtinjector ist aus meiner Sicht zusaetzlich wuenschenswert (Ich liebe Jumper ), ebenso wie der Anschluss fuer ein Hubnetzteil/MicroUSBnetzteil. Der Loetkolben

Muss mich kurz halten im Moment: Master auf 1.4.6 und IO4 auf 1.1.2 geflasht. Rest so gelassen. Kurzer Test und scheint zu laufen. Was passiert wenn ich dem Master auf 1.4.6 bringe, aber das IO4 auf 1.1.0 lasse habe ich nicht probiert. Also weiss ich nicht wieweit die neue Master FW "kompatibel" mit der alten IO4 FW ist. Ist das wirklich das so? Ist das wirklich die gleiche Baustelle? Ich kann aus zeitlichen Gruenden heute nicht testen ob es wirklich nur an Port D und B das Problem gibt. Kann das jemand mal gegenpruefen? Danke und viel Erfolg beim umschiffen! @macdiverone Was muss man genau bei dir machen um das Problem nachzustellen? Der Loetkolben

Hallo ulugutz, schreib doch bitte ein [geloest] vor dem Betreff. Du hast doch selbst den Beitrag eroeffnet. Der Loetkolben

Weitere Erkenntnisse: Die IO4 Firmware 1.1.2 verursacht das Problem! Master downgrade auf 1.1.7, Rest Up to date (IO4 1.1.2): Absturz. Zusaetzlich IO4 downgrade auf 1.1.0, Rest nicht veraendert: Keine Abstuerze. Master wieder auf 1.4.5, IO4 auf 1.1.0 belassen, Rest nicht veraendert: Keine Abstuerze. Es scheint also an der IO4 Firmware 1.1.2 (und wohl auch 1.1.1) zu liegen. Der Loetkolben Edit: PS: Hier koennte wieder das Thema Watchdog stehen. Eine einfache "Voridee" habe ich aber noch: Koenntet ihr 1 oder 2 LED am Masterbrick "blinken" lassen. Von mir aus auch so: 10 Sek. aus - 0,5 Sek. an. Dann kann man wenigstens noch festellen ob der Masterbrick noch lebt und sich nur die Kommunikation verabschiedet hat oder ob "ganz Schluss" ist.

Ich glaube ich habe es! Hier ist es reproduzierbar. Kein wildes clicken notwendig. Vorab schonmal die Konfiguration: WindowsPC -- Brickv1.1.13 -- LAN -- Debian -- USB -- Masterbrick 1.4.5 +A_Temp 1.1.1 +B_Ambient 1.1.0 +C_Humidity 1.1.0 +D_IO4 1.1.2 Edit: Siehe Beitrag darunter Reset am Master druecken fuer einen definierten Zustand Brickv (am Windows PC) aufrufen und Connecten. Ggf. mal aufs Temperatur Bricklet gehen. Sonst nichts machen. Jetzt schickt der brickd PC "sich selbst" zu jeder vollen Minute ein Paket, so dass 3 LEDs am IO4 angehen. Ebenfalls schicken 3 Remote PCs zu vollen Minute plus 2 Sekunden, je ein TCP Paket, welches je eine LED am brickd PC wieder ausmacht. -> Rechnermonitoring mit 1-Bit Anzeige Anders ausgedrueckt: Der lokale PC macht 3 LED an und jeder entfernte Rechner "pustet" (s)eine LED nach ca. 2 Sekunden wieder aus. Jetzt kommts: Wenn man nun nachdem alle 3 LED aus sind, auf den Reiter "IO4" clickt, geht von nun an alles nur noch zaeh weiter. Clicks auf die anderen Bricklet Reiter werden erst nach 4 Sekunden beantwortet. Evtl. ist hier schon "alles platt". Kaempft man sich zum Reiter Setup durch und Disconnected sich, ist ganz schluss! Ein Connect geht nicht mehr und man muss am Masterbrick den Resetknopf druecken. Heisst wohl: Wenn sich nach Aufruf und Connect des Brickviewers die Konfig des IO4 durch TCP Pakete von einem dritten Rechner aendert und man dann den Reiter IO4 am Brickviewer anclickt ist schluss. Kann das bitte mal jemand nachstellen? Ob nur das IO4 reicht oder ob die Portbelegung exact so sein muss erschliesst sich mir nicht. Per "lsusb" ist das Brick noch zu sehen. Der Loetkolben

So bin nun zu Hause. Edit: Bitte erst den Beitrag unter diesem Beitrag lesen. Das Problem mit dem lokalen Windows PC besteht zwar noch, aber ich kann es noch nicht zuverlaessig reproduzieren. Reset am Masterbrick und alles laeuft wieder. Nun sitze ich am einem Windows PC, Masterbrick am Debian Rechner. Rufe den Brickv auf und mache einen Reset per brickv. Clicke munter bis lustig auf den Reitern rum. Die Antworten werden langsamer (Anzeige des neuen Reiters). Alles bleibt stabil. Eine Minute spaeter das gleiche Spiel. Antwortzeiten werden langsamer. Einmal Disconnect-Connect mit Brickviewer und es kommt keine Antwort. "Weg ist er." Nun mache ich ein Update der FW von 1.4.0 auf die aktuelle 1.4.5 am PC. Clicke munter auf den Reitern rum, nur die Antwortzeiten werden langsamer. Masterbrick weg vom PC, wieder an dem Debian PC. Connect mit brickv und langsame Anzeige der Reiter. Ohha! Nun ein Disconnect und Connect. Siehe da, keine Verbindung. "Weg ist er." Ein Resetbuttondruck am Masterbrick brachte alles wieder ins Lot. Ich fasse mal zusammen: Wenn der Masterbrick in einen Zustand kommt wo er nur langsam antwortet, sich dann der Brickv Disconnected und wieder Connected ist schluss mit der Kommunication. Der instabile Zustand kann hervorgerufen werden durch wildes und buntes klicken auf die Reiter oder aber anscheinend nach einem Reset per Button. (Siehe ersten Beitrag des Threads) Ich forsche weiter. Der Loetkolben EDIT: Nachdem ich den Beitrag hier drunter mit dem reproduzierbaren Ablauf erstellt habe frage ich micht, wie ich am lokalen PC es auch geschafft habe den Brick zum Absturz zu bringen, da hier keine Pakete von anderen Rechnern ankommen. Vielleicht haengt es aber auch nur mit dem Aufruf des IO4 Reiters zusammen.

Wenn ich mich richtig erinnere ist auch dieser Gedanke schon bei Tinkerforge auf der grossen ToDo Liste. Da wird sicherlich eine Loesung geben die Aufwand und Nutzen in Einklang bringen wird. Gerade bei den remote genutzen Stacks ist Stabilitaet wichtig! Klare Zustimmung! Der Loetkolben.

Och. Entschuldigung, aber da waere ich nicht drauf gekommen. Was haelst du von einer Messagebox die nach dem Resetknopf druecken erscheint und kurz erklaert, dass sich der Brick gleich wieder meldet und der Brickviewer die Werte dann automatisch neu einliest und das im Viewer anzeigt? -->>> brickd Bug. Erklaerung ab hier: Da hast du Recht. Das mit dem Port hat mich auch stuzig gemacht und ich habe gerade ein wenig geprueft und einen Nebenkriegschauplatz gefunden. Der brickd fuehrt uns hier hinters Licht. Siehe hier: #reboot ~~~ Pause ~~~ #uptime up 2 min #/etc/init.d/brickd start Starting Brick Daemon: brickd. #/etc/init.d/brickd stop Stopping Brick Daemon: start-stop-daemon: warning: failed to kill 1039: No such process #ls -l /var/log/brickd.log -rw-rw-rw- 1 root root 710 25. Okt 19:05 /var/log/brickd.log #Mit bekanntem Inhalt. und nun Du? Das Problem erkennen wir beide! Nach dem Reboot ist bereits ein brickd gestartet worden. DUMMERWEISE kann man aber nochmals einen brickd starten. Hier mit der PID 1039. Der bricht aber ab (ohne das man es sieht), schreibt das Logfile und setzt noch die KILLPID auf 1039. Welche PID der brickd hat, der beim reboot gestartet wurde ist nicht bekannt. Ein "/etc/init.d/brickd stop" versucht nun PID 1039 zu stoppen. Diesen Prozess gibt es aber nicht. DESHALB habe ich das Logfile falsch interpretiert. Sorry. # ps -ef|grep brickd root 890 1 0 19:03 ? 00:00:01 python /usr/share/brickd/brickd_linux.py Das ist der brickd mit der PID 890 der nach dem reboot automatisch gestartet wurde. Deshalb: Bitte den brickd ueberpruefen lassen ob schon ein brickd laeuft und dann garnicht erst versuchen eine 2. Instanz zu starten die dann die KILLPID umsetzt. -> "brickd already running with PIDxxx" Edit: Gerade installiert: Der brickd 1.0.10 verhaelt sich genauso. Der Loetkolben

Hallo photron, danke erstmal fuer die Unterstuetzung. Ich versuche das Problem weiter einzugrenzen. Es kommt nur vor wenn man "spielt". Also Firmware updatedet, Resets ausfuehrt oder mit dem Brickv spielt. Im normalen Betrieb ist dieser Stack ganz artig. Durch Deine Antworten komme ich zu folgender Zusatzfrage: Muss ich nach einem Reset des Masterbricks, bevor ich einen Temperaturwert per TCP/netcat abhole, ein "Enumerate" an den Stack schicken oder macht der das intern schon alleine direkt nach dem Reset? Ich denke nein, da die Bricklets gleich bleiben und der Masterbrick nach einem Reset seine Zuordnungen hoffentlich wieder selbst aufbaut. Der Loetkolben

#dpkg -l |grep brickd ii brickd 1.0.9 Brick Daemon Damit ich sehen kann ob das Bricklet wirklich die neue FW hat. Hmm lass mich mal ueberlegen. ... Wuerde nach einem flashen des Bricklets der Brickviewer die neuen Firmwarestaende automatisch einlesen sobald sich der Masterbrick mit dem brickd wieder verbunden hat? Ne, oder? Weg = Nicht mehr erreichbar. Der Button "Connect" im Brickv wechselt noch auf "Disconnect" aber es erscheinen keine Reiter mehr. Das geht auch jetzt noch. Der Brickv hat keine Fehlermeldungen gezeigt. lsusb hatte das Brick noch angezeigt, aber als ich dann mit dem Tool "usbreset" auf das Geraet zugegriffen habe kam schon ein "Device not found" zurueck. Bei einem erneuten lsusb war es dann auch nicht mehr zu sehen. Selbst nach einem Reboot ist kein Masterbrick zu sehen. Komplettes brickd.log. Es ist kein Debugging eingeschaltet. Wenn ich das richtig sehe kommen diese Meldungen und vom reboot der Maschine als der brickd versuchte sich zum Brick zu connecten. Ein "/etc/init.d/brickd start" erzeugen die gleichen Meldungen nochmal. Traceback (most recent call last): File "/usr/share/brickd/brickd_linux.py", line 157, in <module> brickd.daemonize() File "/usr/share/brickd/brickd_linux.py", line 145, in daemonize self.start() File "/usr/share/brickd/brickd_linux.py", line 85, in start reactor.listenTCP(config.PORT, BrickProtocolFactory()) File "/usr/lib/python2.6/dist-packages/twisted/internet/posixbase.py", line 419, in listenTCP p.startListening() File "/usr/lib/python2.6/dist-packages/twisted/internet/tcp.py", line 855, in startListening raise CannotListenError, (self.interface, self.port, le) twisted.internet.error.CannotListenError: Couldn't listen on any:4223: [Errno 98] Address already in use. Welche Kommunikation? Brickviewer mit dem Masterbrick. Also genauso wie beschrieben. Welche Versionen? Firmware, brickd oder brickv? Masterbrick 1.1.7 mit brickd 1.0.0? Nein, da das nichts mit einander zu tun hat und das auch nicht sinnvoll ist im Allgemeinen. OK, dann aber nochmals die Frage: Wird die geflashte Firmwareversion im Brickviewer nach dem Flashen und dem Reset automatisch angezeigt ohne sich neu connecten zu muessen? Da der Rechner bei mir ist, kann ich nachher wieder mal "Reset" druecken. Der Loetkolben

Antwort zwischendurch. Nein. Es kann sein, dass von einem Server ausserhalb die Sensoren per Cron (TCP/netcat) abgefragt werden. Alle 10 Minuten ein Request, also kein Dauerrequest. Ein Enumerate wird nicht durchgefuehrt. Kommt da eine Nachtigall? Der Loetkolben

Mache ich nun ein neues Thema auf oder stecke ich mein Problem hier rein? ... Also hier. Ich habe remote das IO4 Bricklet (edit: von 1.1.1) auf 1.1.2 geflasht. Debian -- Brickv.1.1.13 -- LAN -- Debian -- Brickd -- USB -- Master1.4.0 Das Flashen hat im Prinzip funktioniert. Nun noch einen Reset im Brickv, damit auch die aktuelle FW aktiv wird. SOFORT mit Brickv Disconnect und Connect hinterher. Nochmals Disconnect und Connect zum testen. Schwups und da war der Master "weg". Er ist nicht mehr erreichbar. Das ist nicht das erste mal gewesen, dass der Masterbrick einen (schnellen) Reconnect nicht ueberlebt hat. Kann das zeitlich mit der WLAN Firmware zu tun haben? Dieser Stack hat zwar kein WLAN, macht aber seit einiger Zeit Probleme. Vielleicht ist auch der Reset selbst nicht schuld daran, sondern der Zugriff via LAN mit dem Brickv. Ich kann mich daran erinnern, dass ich mich 4-5 mal mit dem Brickv in kurzen Abstaenden (ca. alle 2-3 Sekunden) zum Brickd verbunden habe und danach war die Kommunikation weg. In den alten Versionen hat es bei solchen Spielereien keine Probleme gegeben. Ist der Masterbrick nach einem Reset oder Disconnect vielleicht noch nicht richtig bereit einen neuen Connect anzunehmen? Featurerequest: Koennte der Brickv nicht automatisch einen Disconnect machen wenn man den Resetbutton drueckt? Gibt es evtl. dadurch Probleme? Der Loetkolben

Hat hier gerade jemand "Weihnachten" und "Ethernet Extension" in einem Satz gesagt? Danke fuer die Infos. Der Loetkolben

Nachdem sich mal wieder ein Masterbrick aufgehangen hat, habe ich mich mit den USB Devices beschaeftigen muessen und es ist mir folgendes aufgefallen: #lsusb Bus 003 Device 027: ID 16d0:063d GrauTec #update-usbids #lsusb Bus 003 Device 027: ID 16d0:063d MCS Passt das so? Wer oder was ist "MCS"? Der Loetkolben

Hallo photron, Ja das war mir klar. Ich hatte eine aktuelle FW drauf, die schon WLAN konnte. Ich bekomme es nicht mehr genau zusammen wie es war, aber die Extension hat sicht nicht mit dem WLAN verbunden, obwohl ich alle Parameter richtig eingestellt hatte. Ein neuflashen der Masterfirmware brachte dann den Erfolgt. Ob es wirklich am neuflashen lag oder Murphy es aufgegeben hat mit zu aergern kann ich nicht sagen. Seitdem laeuft der Stack aber reibungslos. Verbesserungsvorschlag: FW mit Checksumme sichern und der Master prueft dies beim booten??? Alternative: Im Brickviewer kann man die FW testen. Also auslesen und mit einem CRC Code (Fingerprint) vergleichen den es zu jeder FW gibt. Der Loetkolben

@TF Da wir nicht genau wissen woran es liegt, wuerde mich aber interessieren, ob in der Bricklet FW Informationen sind an welchem Ports die Bricklets arbeiten duerfen und an welchen nicht. Wie kamt ihr darauf diesen Rat zu geben? Muss man damit rechnen, dass bei einer Erstinbetrebnahme einer Masterextension die FW (Brick oder Brickelt) nicht klarkommt?? Meine WLAN Extension habe ich seinerzeit erst erfolgreich zum laufen bekommen, als ich den Masterbrick neu geflasht habe. Das kann sicher Zufall gewesen sein. Ggesicherherte Erkenntnisse habe ich nicht, aber die Master-FW war vor dem aufstecken der WLAN Extension aktuell und der Masterbrick arbeitete einwandfrei. Ueber Infos wuerde ich micht freuen. Der Loetkolben

Danke erstmal fuer die Info und den Gegencheck. Ich hatte zuerst auch auf den Dokuseiten geschaut aber nichts gefunden. Bitte noch einen Hinweis in den Brickv beim speichern. Denkt ihr nochmals ueber die LED als Indikator des Power Mode nach. Sollten wir an so einem schoenen Sonntag nicht noch was sinnvolles machen? Der Loetkolben

Hallo zusammen, ich schaffe es nicht den "Low Power" Mode dauerhaft zu setzen. Nachdem ich ihn ausgewaehlt habe und "Save WIFI Configuration" gewaehlt habe habe kommt eine "Check OK" Box zurueck. Prima. Ein Disconnect und Connect via Brickviewer zeigt mir weiterhin den "Low Power" Mode an. Aber weder einen Reset via Brickviewer noch einen Powercycle ueberlebt diese Einstellung. Es steht dann wieder "Full Speed" dort. Was mache ich falsch? Wie wuerde man den "Low Power" Mode am WLAN Brick erkennen? Wuerde dann vielleicht die gruene LED langsam blinken oder dunkler sein? Master FW. 1.4.5 Der Loetkolben.

Hallo ArcaneDraconum, habe hier gerade mal einen WLAN Stapel auf die aktuelle 1.45 geflasht. Kein Probleme. Temp,Ambient,Humidity,IO4 + Master 1.4.5 + WLAN. Kann es sein, dass zufaelligerweise ein Brickletkabel kaputt ist (Draht ab oder Kontakte werden reingedrueckt) und du es so benutzt hast, dass es zu diesem Ergebnis kommt? Zieh mal vorsichtig an jedem Draht und schaue ob du ihn aus dem Stecker ziehen kannst. Ist es egal an welchem Port das IO4 steckt? Alle Kontakte der Stecker am Master sind in Ordnung? Ich wuerde einen Hardwarefehler immer noch nicht ausschliessen. Der Loetkolben.