remotecontrol

Was soll das sein? Entweder gibt es vorgesehene Zugangswege oder nicht. Alles andere sind eher nicht vorgesehene Lücken, aber keine geplanten Zugangswege. Immerhin gibt es zwei Zugangswege: die APIs in verschiedenen Sprachen und das TCP/IP Protokoll. Ob die API intern diverse Threads nutzt ist mir erstmal egal, dafür ist es ja die API, um die Threads muss ich mich nicht kümmern. Das TCP/IP Protokoll wurde auch schon in diversen Projekten genutzt; ich selber nutze das auch zur Stack-Emulation und damit zum automatisiertem Test -> geht super. Und wenn die API die alles Erfüllende hyper Moderne wäre: wo bliebe denn da der Spaß, sich selber Gedanken zu machen? Ist doch gerade zum Basteln gedacht, darum Tinkerforge. Gerade die einfache API bringt mich dazu, zu überlegen wie ich das z.B. in C++ so anbinde, damit ich mich in meiner Anwendung nicht mehr drum kümmern muss, ob ein V1, V2 oder V3 Bricklet angestöpselt ist und nur noch "sage": gibt es ein Bricklet mit der Funktionlität "Temperatur Sensor" oder "Display". Und siehe da: der Tausch des LCD 20x4 durch LCD 128x64 macht der Anwendung nichts aus ...

Die Meldung "No Brick in Bootloader found" sollte ja nur beim Flashen kommen, das machst Du ja eher selten. Hast Du im Brick-Viewer einfach mal auf den "Connect" Button gedrückt? Was wird da angezeigt ?

/dev/tty.XX ist eher eine serielle Console, ssh arbeitet aber nicht mit seriellen Consolen (ist mir zumindest nicht bekannt). D.h. für die Nutzung von tty musst Du mal nach Clients für serielle Consolen schauen.

Willst Du den RED mal "ins Netz" bringen oder Standalone ohne jeglichen Netzanschluß betreiben? Mit Netz ist es am einfachsten, wenn Du initial über Brickv mal die Netz-Konfiguration machst und danach mit "ssh <hostname>" alles Übrige.

Eine andere einfache Möglichkeit ist SSH: ssh -L 4300:remote:4223 remote das macht ein Port Forwarding von remote:4223 auf localhost:4300. Danach kann ich mich mit einem lokal gestarten Brick-Viewer gegen localhost:4300 verbinden und bekomme die Devices des Hosts "remote" angezeigt ('remote' ist nur Beispielname).

Hallo TF-Team, noch eine Frage / Problemchem mit dem AirQuality-Bricklet. Da ich mir den Verlauf auf dem LCD als Graph anzeigen lasse, ist mir aufgefallen, dass es immer wieder Ausreisser in den Werten gibt, die eigentlich nicht vorkommen können (Luftdruck unter 800). Das passiert ca. 3x pro Tag mit dem Callback für alle Werte. Jetzt habe ich das mal protokolliert und: wenn es so einen Aussetzer gibt, kommen immer dieselben Werte, also nicht nur eine größere Abweichung, sondern jeweils ein bestimmter Wert, pro Kanal anders aber konstant: 2019-01-21 19:51:40.605472 AirQualitySensor air pressure is 74657 (temp 3056) => out of range ignored ! 2019-01-21 22:01:04.800035 AirQualitySensor air pressure is 74657 (temp 3056) => out of range ignored ! 2019-01-22 06:57:31.503578 AirQualitySensor air pressure is 74657 (temp 3056) => out of range ignored ! 2019-01-22 08:54:31.803379 AirQualitySensor air pressure is 74657 (temp 3060) => out of range ignored ! Jetzt wo ich es weiss kann ich das abfangen, weil der Luftdruck jenseits sinnvoller Werte ist, bei der Temperatur sieht das anders aus (30.6° geht noch). Aber habt Ihr noch eine Idee, woran das liegen könnte? Eine Störung in der Übertragung sollte nicht immer exakt denselben Wert erzeugen - oder ? Ich habe einen Stack mit 3 Mastern + 10 Bricklets, also nicht ganz simpel, aber alle laufen per Callback. Sollte nicht so viel IO drauf sein.

OK, danke, das erklärt das Verhalten. Dann aber noch eine Frage / Verbesserungsvorschlag: Kann man das Outdoor Weather Bricklet so ändern, dass es Sensoren die 8h-12h keinen Wert geliefert haben aus der Liste erkannter Sensoren wirft? Aktuell bleiben diese Leichen ewig drin, und der smallint für die Sekunden seit letztem Update bekommt nach etwas mehr als 12h einen Überlauf und sieht "frisch" aus.

Hallo TF-Team, kann es sein dass der TH-6148 seine ID ändert ? Ich habe nämlich 4 Sensoren und jedem per ID einen Namen zugeordnet und jetzt zeigt mir das Bricklet 5 Sensoren an. Wobei eine unbekannte ID jetzt exakt die Luftfeuchte und Temperatur eines meiner Sensoren anzeigt (wenn ich den in die Hand nehme geht der Wert mit). Falls sich die ID ändert: von was hängt das ab? In der Doku steht "beim erstmaligen Starten" => bei erster Inbetriebnahme ? => bei jedem Batteriewechsel ?

Wenn ich das gerade richtig gelesen habe ist "praxis live" eine IDE die intern auf der Java API aufsetzt => du programmierst damit Java. Bindings für Java gibt es, sollte gehen. Wie man die da einbindet kann ich aber nicht sagen - kenne praxis live nicht. Ansonsten ist die Frage nach der "richtigen" Programmiersprache eher spirituell

Danke jetzt tut alles

Kann es sein, dass der Bug mit der Temperatur-Kalibrierung wieder drin ist? Mein Brickv zeigte nämlich schon Version 2.0.1 an => hab's überschrieben und wenn ich jetzt mit Wert 160 die Temperatur kalibriere bin ich auf einmal weit unter -100° C, dabei sollten ja nur 1.6° abgezogen werden?? Ich meine das hier: https://www.tinkerunity.org/forum/index.php/topic,4689.0.html

Hallo TF Team, mit gcc 8.2 erhalte ich beim Aufruf von air_quality_get_iaq_index einen Absturz wegen Stack corruption (bei älteren GCC Versionen passiert das nicht !!): ==5490== Process terminating with default action of signal 6 (SIGABRT): dumping core ==5490== at 0x4F05D7F: raise (in /usr/lib/libc-2.28.so) ==5490== by 0x4EF0671: abort (in /usr/lib/libc-2.28.so) ==5490== by 0x4F48877: __libc_message (in /usr/lib/libc-2.28.so) ==5490== by 0x4FDB414: __fortify_fail_abort (in /usr/lib/libc-2.28.so) ==5490== by 0x4FDB3C5: __stack_chk_fail (in /usr/lib/libc-2.28.so) ==5490== by 0x204CB9: air_quality_get_iaq_index (bricklet_air_quality.cpp:633) ==5490== by 0x48E2892: brickapi::AirQualitySensor::readValue(brickapi::SensorItem::CHANNEL_NO) (AirQualitySensor.cpp:147) ==5490== by 0xFF000577: ==5490== by 0x52399AF: ich habe mir den Bricklet-Code mal angesehen: BootloaderHandleMessageResponse get_iaq_index(const GetIAQIndex *data, GetIAQIndex_Response *response) { response->header.length = sizeof(GetAllValues_Response); response->iaq_index = voc_get_iaq_index(); response->iaq_index_accuracy = voc_get_iaq_index_accuracy(); return HANDLE_MESSAGE_RESPONSE_NEW_MESSAGE; } ist das hier nicht falsch: da steht response->header.length = sizeof(GetAllValues_Response); da wird doch die falsche Response-Größe zurück geliefert - oder nicht?

Schon mal den Stecker am Bricklet + Master kontrolliert ob alle PINs OK sind? Hatte erst gestern ähnliches Problem mit RemoteSwitch: Bricklet erkannt aber keine Callbacks => der äußere PIN war verbogen. Zum Glück konnte ich den noch richten.

To make it more precise: I trigger the enumerate callback, then wait 250ms and check how many devices are listed in my internal structures meanwhile; not enough => wait again. If there are not enough devices after for example 2 seconds I abort, there is something wrong. The enumeration is normally done quite fast (below 0.5 seconds).

The call to ipcon_enumerate triggers callbacks and it depends on what you're doing in the callback. You should only update internal structures in the callback. The main thread should wait some time so that the callbacks are done and everything is updated. the "while (true)" from the sample is just an outline - don't use it exactly that way without wait times, this would consume 100% CPU !

There is an enumeration API for the connection and this returns the connected UIDs and device types. First introduction how to use enumeration is here https://www.tinkerforge.com/en/doc/Tutorials/Tutorial_Rugged/Tutorial.html#tutorial-rugged-approach And you can read the Pascal API doc (I don't use Pascal, so I have no sample).

Hallo TF Team, es scheint, als könnte man einen Button nicht exakt bündig zum rechten oder unteren Rand platzieren - wenn man den letzten Pixel nutzt wird der Button nicht mehr angezeigt Beispiel lcd_128x64_set_gui_button(lcd, 0, 0, 47, 21, 16, "XX"); => geht: 47 mit 16 Höhe => letzter Pixel ist in Zeile 62 (nicht 63 !) lcd_128x64_set_gui_button(lcd, 0, 0, 48, 21, 16, "XX"); => geht nicht mehr, Button wird nicht angezeigt Ist das so gewollt oder eher ein Bricklet Bug, der auf "y + height >= 64" prüft. Letzeres stimmt eigentlich nicht, denn bei y=63 und Höhe=1 liegt der Button ja noch in Zeile 63 - oder ?

Die Luftfeuchtigkeit steht ja in direktem Zusammenhang zur Temperatur: wenn sich der Sensor intern erwärmt, wird die Luftfeuchte dann noch korrekt berechnet ?

Wenn ich jetzt 160 übergebe geht die Temperatur um 1.6° runter -> funktioniert wie dokumentiert

Meine Platte ist oben plan: die Schraube die durch die Platte geht hat einen Senkkopf und ich habe 1x mit 3mm durchgebohrt und 1x mit 4mm ganz leicht angebohrt. Das hat schon gereicht, die Schraube konnte ich im Kunststoff versenken. Was natürlich nicht eben ist, sind die Schraubenschlitze, die sieht man halt. Mir reicht das aber so. Wenn man da eine zweite Platte drauf legt wäre aber schon wieder alles plan. 3 Platten braucht man eigentlich nicht.

Das bedeutet Du schaltest über das Relais die Netzteile für die LED Strahler oder haben die direkt 220V Anschluß? Ich vermute, dass es beim Schalten einen kleinen Zündfunken gibt und das das System stört. Für 220V habe ich selber keine erprobte Lösung, aber das mit dem Varistor könnte klappen.

Was genau schaltest Du mit dem Dual-Relay (wie viel Strom und Spannung und welche Art Last) und welche Version des Bricklets nutzt Du? Ich hatte auch den Effekt, dass das Relais den kompletten Stapel stören kann, je nach Art Verbraucher. Hast Du das schon gelesen: https://www.tinkerforge.com/de/doc/Hardware/Bricklets/Dual_Relay.html#dual-relay-inductive-load-switching

Hallo zusammen, noch eine Frage zum AirQuality Bricklet: schließe ich den Master an USB an und lasse mir die Werte im Brickviewer anzeigen, dann steigt die Temperatur kurz nach dem Einschalten langsam um ca. 1.6°C an bis sie sich dann einpendelt. Ich Bricklet liegt neben einem Thermometer welches 21.1° anzeigt; das Bricklet selber liegt mit 15cm Kabel weg vom Stack und startet bei 20.9°, pendelt sich aber nach 5 Minuten bei 22.5° - 22.6° ein: Erwärmen sich einige Bauteile des Bricklets minimal? Abschalten der LED ändert nichts an dem verhalten. Auch im Vergleich zum normalen Temperatur-Bricklet misst das AirQuality Bricklet bei mir eine deutlich höhere Temperatur.

Hallo TF-Team, in der Doku zur obigen Funktion steht Wenn ich aber schlicht den Wert 1 übergebe, dann geht die gemessene Temperatur um 1°C runter, beim Wert 12 um 12°C. Laut Doku müsste ich aber 100 übergeben, damit der Wert um 1° gesenkt wird. Stimmt da was im Bricklet-Code nicht oder verstehe ich was falsch? Ich hab's zumindest nicht geschafft, um 1.2° (mit Nachkommastelle) zu kalibrieren.

Hallo TF-Team, nur als Anregung: der Klebestreifen im Waagenkit hilf mir nicht wirklich, um den Teller stabil zu befestigen. Ich nutze daher zwei kleine Winkel und Senkschauben im Teller (musste den entsprechend anbohen), um diesen auf den Makerbeams zu befestigen - siehe Bild. Vielleicht bekommt Ihr solche Winkel ja auch ...