rifmetroid

Moin, ich habe einen Energy Manager, an dem 7 Wallboxen angeschlossen werden sollen. Mit einer Box hat alles gut funktioniert. Dann habe ich versucht die anderen 6 Boxen hinzuzufügen. Zuerst wurden auch alle Boxen angezeigt, aber so ca. nach 1-3 Minuten wurden alle Boxen rot dargestellt, oben wurde "interner Fehler" in rot hinterlegt und dann brach die Verbindung zur Weboberfläche vom Energy Manager ab. Alle Boxen sind WARP2 mit der aktuellsten FW (2.2.1), der EM hat die 2.0.2. Habt ihr schon einmal ähnliches gehabt? Morgen habe ich wieder Zugriff auf den EM, dann schaue ich mal, ob ein Neustart etwas bringt und ich irgendwo Fehlerprotokolle ziehen kann. Pingen lässt er sich weiterhin, auch wenn die Weboberfläche nicht mehr erreichbar ist. Grüße rif

Moin zusammen, ich hätte hier auch Interesse. Ein automatisierter Mailversand der csv wäre natürlich das Allerbeste und mit dem geringsten Aufwand für die User verbunden.

Moin zusammen, exakt dasselbe Problem bei mir. Nach einfügen der beiden Zeilen hat es auch funktioniert. Grüße rif

Moin, bei mir ist es der Mosquitto auf dem aktuellsten OpenHab3 Release. Kann leider erst morgen wieder schauen und testen. Rückmeldung folgt.

Moin, dem kann ich mich anschließen, exakt das identische Problem. Warp Charger 1 Pro mit Firmware 1.3.2 Gruß rif

Moin, niemand eine Idee oder schon mal gleiches versucht?

Hallo zusammen, ich habe heute eine Serverraumüberwachungskit in mit Motion Detector in Betrieb genommen. Den Motion Detector kann man ja leider nicht so schön einfach per Klick ins Nagios einfügen. Daher habe ich flux in C# ein kleines Programm geschrieben, welches bei Bewegung eine Mail verschicken soll. Am Rechner funktioniert es natürlich auch einwandfrei, aber wenn ich das Programm auf den RED-Brick übertrage schlägt der Mailversand fehl. Ich schätze mal, dass das mono mit System.Net.Mail oder den weiteren Befehlen nichts anfangen kann. Hat jemand von euch so etwas schon mal versucht oder gibt es noch eine andere Lösung? Hier mein Code fürs Testen: MailMessage mail = new MailMessage(); mail.From = new MailAddress("MotionDetector@mail.de"); mail.To.Add("testmail@mail.de"); //Empfänger mail.Subject = "Bewegung im Serverraum"; mail.Body = string.Format("Um {0} Uhr wurde eine Bewegung im Serverraum erkannt.", DateTime.Now); SmtpClient client = new SmtpClient("smtp.mail.de", 587); try { client.Credentials = new System.Net.NetworkCredential("testmail@mail.de", "Password"); client.EnableSsl = true; client.Send(mail); Console.WriteLine("E-Mail wurde versendet"); } catch (Exception ex) { Console.WriteLine("Fehler beim Senden der E-Mail\n\n{0}", ex.Message); } Console.ReadKey(); Gruß und Danke schon mal! rif

Hallo zusammen, ich habe das Image nun einfach einmal neu auf die Karte aufgespielt und es geht wieder. Wer weiß, was sich dabei verschluckt hat. Thema somit geschlossen. Gruß rif

Hallo zusammen, ich habe mir die Serverraumüberwachung gekauft und eingebaut. Es funktionierte auch alles für ein paar Minuten sehr gut. Ich hatte die E-Mail-Notification eingerichtet und die 2 Temperatursensoren in die Überwachung mit aufgenommen und dann gespeichert. Jetzt kommt nach einem Neustart des RED-Bricks die Meldung "Error occured while trying to get existing rules: Script error 1: No closing qoutation". Hat das schon mal jemand von euch gehabt? Wie bekomme ich das wieder weg. Ich hab den Service "Server Monitoring" schon einmal deaktiviert, rebootet und dann nochmal wieder aktiviert, keine Änderung. Gruß rif

Moin, bist du dir sicher, dass das DistanceBricklet rausfällt? Habt ihr das mal getestet? Der Aufbau sieht für mich auf den Bildern so aus, als ob man die eigentlicht optimal an der Innenseite der oberen Querstreben anbringen könnte und dann einfach nach oben gegen die Holzplatte misst. Damit würdest du am Einfachsten zum Ziel kommen und so, wie es auf den Bildern aussieht ist es doch auch gegen Lichteinwirkung sehr gut geschützt in dem Bereich. Oder habt ihr vor, den Tisch von unten zu beleuchten? Dann ist es in der Tat mit dem DistanceBricklet sehr schwierig, es sei denn man baut eine kleine Holzverschalung rundrum, die genug Spiel gibt, dass das DistanceBricklet nicht abgeschert wird, aber von der Lichteinstrahlung geschützt wird.

Ich würde die DC Power Supply von Phoenix Contact auch nicht unbedingt außer Acht lassen. Teste doch mal, wie sich das Ganze verhält, wenn du die Power Supply außerhalb des Gehäuses hast und nur die TF-Sachen im Gehäuse. Ich kenne einen Anwendungsfall, da haben wir Netzteile quer liegend eingebaut, da gab es nach gewisser Zeit Probleme mit der Wärmeabfuhr in deren Gehäuse, da sie nur für hochkant stehenden Einbau konzipiert waren (Position der Lüftungsschlitze beachten, sollten immer oben und unten sein).

Moin, coole Sache, hat das vielleicht auch schon mal jemand mit nem QNAP-System versucht?

Auch nur mal kurz in den Raum geworfen? Warum hast du nen Raspi drin, wenn du das Programm eh auf nem anderen Rechner laufen hast? Dann einfach die LAN oder WLAN Extension nehmen, StepDown drunter und direkt anschließen. Ich würde auch vermuten, dass der Raspi und die Spannungsversorgung da die Schwierigkeiten verursacht. Gruß rif

Moin, gibt es hierzu schon eine Entscheidung von TF? In der Timeline konnte ich dazu nichts finden, wäre aber sehr an dem Thema interessiert. Gruß rif

Nur als Hinweis, dass der Anfang dafür schon gemacht wurde: http://www.tinkerunity.org/forum/index.php/topic,1574.msg10415.html#msg10415

Hey, in the german forum is a thread about that topic. AuronX and The_Real_Black are writing a software like this. It's written in C# and not all is implemented yet, but it is a nice beginning. http://www.tinkerunity.org/forum/index.php/topic,1574.msg10415.html#msg10415

Moin Chris, du kannst 3 oder auch mehr Terrarien über einen Raspberry steuern. Dafür brauchst du einfach je 3 mal: - Step Down Power Supply (oder alternative Spannungsversorgung per USB für den Master) - Masterbrick (je nachdem wie viele Bricklets du anschließen möchtest auch mehr von den Masterbricks) - WIFI Master Extension oder RS485 Master Extension - Bricklets für die Sensoren und Aktoren Dann musst du ein Programm schreiben, welches die Tinkerforge-Module über WLAN ausliest und dir irgendwie zur Verfügung stellt (das ist dann deine programmiererische Freiheit, wie du das gestaltest). Für die Anzeige der Daten auf einem Tablet oder Smartphone kannst du natürlich auch gleich eine Webseite auf dem PI programmieren, so dass du nur diese aufrufen musst. Alternativ besteht natürlich auch die Möglichkeit dir eine eigene App zu schreiben. Wenn du weitere Fragen hast, dann immer her damit, dafür ist ja ein Forum da Gruß rif

Ich bin eher in der Regelungstechnik unterwegs und nutze Tinkerforge um Signale zu simulieren. Von daher habe ich ein paar digitale und analoge Ein- und Ausgänge dran. Das läppert sich dann schon ziemlich schnell.

Du kannst glaub ich sogar bis zu acht Master stapeln um genügend Anschlüsse zu haben. Ich habe in einem Stack aktuell ne Step-Down, dann 6 Master und dann das Wifi-Modul. Klappt bestens.

Ich hätte da auch sehr großes Interesse dran, vor allem auf den +-10 Volt Bereich (Automatisierungstechnik).

Moin moin, richtig coole Sache, gleich mal gezogen. Werde ich mir nächste Woche gleich mal anschauen und eventuell auch erweitern, wenn ich Zeit dazu finde. Gruß rif

Bedarf

@TF Wie sieht es denn nun jetzt hier aus? Habt ihr schon eine Entscheidung getroffen ob nun C, Python, oder TinkerBasic?

Ich würde auch definitiv sagen die 1000 Nachrichten pro Sekunde sind momentan genug. Viel wichtiger ist das man erstmal überhaupt die Möglichkeit bekommt, OnDevice zu programmieren (dann aber schon die 1000 Nachrichten ausreizen sollen könnte -> C-API). Falls es dann wirklich mal Anwendungen gibt, die eine höhere Auflösung erfordern, kann man immer noch daran arbeiten. Wobei ich denke, dass solche Anforderungen hauptsächlich aus der Industrie kommen werden und die dann evtl. auch ein bißchen Geld dafür locker machen würden.

Moin, kurze Nachfrage zu der WIFI/Ethernet Diskussion. Warum sollte ich die nutzen, wenn ich das Programm OnDevice laufen lassen kann? Die einzige Sache, die mir dazu einfällt, wäre es Sachen zu visualisieren, aber da ist wohl klar, dass man dafür keine 1000 Nachrichten pro Sekunde benötigt. In jedem Steuerungssystem ist das genauso, der schnell laufende Steuerungsprozess läuft auf der Hardware direkt und stellt nur ein Prozessabbild nach außen dar, damit das Ganze auch angezeigt werden kann und dabei ist es relativ egal, ob ich 1000 oder 500 Nachrichten pro Sekunde habe, so schnell bekommt der bedienende Mensch das gar nicht mit. Von daher finde ich diese Diskussion zu WIFI/Ethernet etwas überflüssig. Ich würde gerne meinen Stack OnDevice füttern und Steuerungsprozesse unter 1ms ablaufen lassen, freunde mich aber erstmal auch gerne mit der maximalen 1ms an, wenn es denn erstmal überhaupt geht. Dann möchte ich das Ganze aber auch von außen bedienen können, da ist mir aber die Geschwindigkeit nicht so wichtig, es muss halt nur bedienbar sein (WIFI, USB, Ethernet). Oder habe ich da jetzt falsch gedacht oder etwas übersehen? Gruß rif EDIT: Warum ich 1000 Nachrichten oder mehr pro Sekunde benötige? Ich nutze Tinkerforge um Echtzeitsteuerungssysteme zu testen (TF ist da etwas leichter als 300T Stahl). Ich bastel mir aus TF einen Simulator der einfach elektrische Signale generiert, die dann aber zeitlich ungefähr dem entsprechen sollten, was der echte Stahlkoloss produziert und da sind wir leider schon im Bereich von unter 1ms. Aber jetzt geht es auch mit 1ms schon recht gut. Das ganze noch OnDevice und dann einfach mit nem Handy und der WIFI-Extension bedienbar, das wäre der Knaller.