KeyOz

Ich spiele z.Z. auch mit MQTT rum. Habe dazu auf meinem OpenWRT Router einen MQTT Broker am laufen und mir in Python einen Proxy geschrieben, der sich an den Server anmeldet und alles was kommt in eine MYSQL-Datenbank schreibt. Daten kommen z.Z. von einer Wetterstation mit Tinkerforge-Modulen und von einem anderen Pythonscript was anderweitige Daten sammelt. Im moment arbeite ich gerade an einer universellen PHP-Software zum Visualisieren dieser Daten, da ich vor habe noch mehrere Sensoren zu betreiben (Solaranlage ect.), welche dann auch ihre Daten per MQTT liefern. Bei der ganzen probiererei kam mir da so eine Idee. Meine Tinkerforge Wetterstation habe ich mit einem WLAN Modul angebunden. Wenn ich das richtig sehe werkelt ja auch dem WLan und auch auf dem Lan-Modul ein Eigener Prozessor. Wäre denn in diesem Prozessor noch genug Platz um hier einen Stand Alone MQTT Client zu integrieren, der, Konfigurierbar, sich in gewissen Zeitabständen, bei einem Broker meldet und dort seine Daten abliefert? Das würde für reine Datenerfassung ein "Rechner" der die Tinkerforge Module Pollt und Daten abfragt überflüssig machen.

Wow.. Tolles Projekt. So etwas könnte ich auch gebrauchen. Halte uns bitte auf dem Laufenden wie es voran geht und vor allem Details details details für ein eventuelles nachbauen.

Hi, vielen Dank.. Funktioniert. Super..

Danke für den Tipp, doch kann ich ja aus der Statischen Funktion auch nicht auf Objekte der Instanz der klasse zugreifen. (Ich will etwas in die UI Schreiben z.Z. )

Hallo, ich versuche gerade mit C++ und QT eine kleine Anwendung zu erstellen, um einen Steppermotor zu betreiben. Ich habe allerdings ein Problem mit Callbacks und der OOP von C++. Ich möchte nach dem Verbinden zum brickd ein Callback von "IPCON_CALLBACK_DISCONNECTD" erstellen um Verbindungsabbruch abzufangen. Folgend ein kurzer Ausschnit der Relevanten Sachen: dlg_Main.h class dlg_Main : public QMainWindow { Q_OBJECT public: void cb_IP_Disconnect(uint8_t disconnect_reason, void *user_data); private: IPConnection IPCon; }; und dazu die dlg_Main.cpp void dlg_Main::cb_IP_Disconnect(uint8_t disconnect_reason, void *user_data) { // Hier Aktion wenn Verbindung beendet wurde. } void dlg_Main::slot_Connect() { ipcon_create(&IPCon); if (ipcon_connect(&IPCon, "localhost", 4223) < 0) { qDebug("Can't Connect to "); } else { qDebug("Connected"); ipcon_register_callback(&IPCon, IPCON_CALLBACK_DISCONNECTED, (void *)cb_IP_Disconnect, NULL); } } Das ganze Funktioniert leider nicht, wenn die Callback-Funktion sich in der Klasse befindet. Ich bekomme da error: invalid use of member function (did you forget the '()' ?) ipcon_register_callback(&IPCon, IPCON_CALLBACK_DISCONNECTED, (void *)cb_IP_Disconnect, NULL); als Fehler beim Compilieren. Mache ich die Callback-Funktion außerhalb ohne die Klasse kann ich sie aufrufen aber nicht aus der Funktion auf das Objekt der Klasse zugreifen. Hat vielleicht jemand einen Tipp wie ich das ganze bewerkstelligen kann? Danke

Hallo, zur anzeige der Wetterdaten auf meinem Android habe ich einfach eine extra version der Webseite gebaut die die Daten mit Hilfe von JQuery Mobil anzeigt. Da brauche ich nicht eine extra App dafür. Auch wenn eine extra App schon Vorteile hat.

Ja sicher.. Gibs schon aber der Sinn dieser neuen Platine wäre das Prozessorinternen Ethernetinterface zu nutzen. Spart halt die mühe einen eigenen Treiber zu erstellen. Nur so ne idee.

Die IDE gibts schon. (Siehe Link). Sie sollte dann halt nur mit installiert sein. Macht natürlich nur sinn für Scriptsprachen oder man müsste noch was basteln um dann den Compiler anzuwerfen.

Hallo, also mit Persönlich gefällt Variante 2 und 3 am besten wobei ich doch die 3 da noch vorziehe. Man kann hier halt gleich direkt 4 Bricklets anstecken. Das gefällt mir und würde mir momentan in meiner geplanten Heimautomation erst mal vollkommen reichen. Variante 1 find ich irgendwie nicht so gut weil hier ein Ethernet vorhanden ist und dieses ja denke ich mal viel genutzt wird. Eine Idee für Variante 1 wäre jedoch, wenn es vom Platz her ginge, unten auf der Platine einen Connector zu haben, auf den man eine kleine Zusatzplatine mit Ethernetbuchse und den entsprechenden Treiber dafür aufstecken könnte. Zusätzlich könnte da dann ja noch ein USB-Hub und ein paar zusätzliche USB-Ports mit drauf sein. So könnte man die Variante 1 zur 2 upgraden, Preislich sollte sich das dann zusammen auch auf dem Preis der Variante 2 befinden, man wäre hier Flexibel, spart sich den Treiber für die Ethernet-Extention und der Formfacktor wäre auch erhalten geblieben. Cool wäre auch wenn man über das Webinterface dann nicht nur Scripte hochladen könnte, sondern es gleich eine Online-IDE geben würde wo man diese bearbeiten kann. So etwas nutze ich z.Z. auf meinem OpenWRT-Router der meine Wetterstation abfragt. (http://codiad.com/)

So hab heute mal wieder zeit gefunden zum weiter schauen. Alles Angeschlossen und siehe da, er geht wieder. Ein paar Tage in der Warmen Wohnung haben da wohl wunder gewirkt. Ich werde mal schauen ob ich ihn für den weiteren Außeneinsatz irgendwie besser Wetterfest verpacken kann, so das er aber auch noch realistische Werte für meine Wetterstation liefern kann.

So hab mal nachgemessen.. Die beiden Verbindungen haben laut Multimeter durchgang und sind i.o. Habe das Bricklet auch draußen im einsatz für meine Wetterstation.

Hallo, habe seit ein paar Tagen das selbe Problem. Wenn es mit dem Löten einer kleinen Brücke erledigt ist, würde ich dieses tun. Oder soll ich ihn doch lieber zum umtauschen einschicken?

Selbiges habe ich demnächst auch vor zu bauen und will dann dafür auch eine kleine Steursoftware für das anfahren der Temperaturpunkte schreiben. Wie hast du die Steuerung auf dem Rechner umgesetzt? Man muss das Rad ja nicht andauernd neu erfinden.

Mit dem MIT AppInventor selber was bauen..?

Hallo, ja mit nohup geht das, aber die bessere Variante ist screen. Damit kann man sich die in den Hintergrund geschobene Session jederzeit wieder vorholen.