AuronX

Dachte mir schon, dass es ein wenig um das "selbermachen" geht.

Ich weise nochmal auf meine geringen elektrotechnischen Kenntnisse hin, aber meines erachtens passiert für die Zeit in der beide Quellen aufgeschaltet sind folgendes:

Die Quelle die die höhere SPannung hat legt bei der andern Quelle diese Spannung an. Am Ende bedeutet das, dass für diesen Moment die kleinere Quelle ein Verbraucher mit sehr geringer Spannung (halt die Differenz aus beiden Spannungen) wird. Also vermutlich würde das Netzteil entweder kurz die Akkus mitladen oder die Akkus würden ins Netzteil einspeisen...

Die echte Frage ist halt, ob das ein Problem ist, insbesondere wenn man die kurze Zeit bedenkt. Vielleicht ist das aber auch gar nicht richtig was ich schreibe... ist ja schließlich Elektrotechnik ^^

Dann brauchst du vermutlich Dioden, damit der Strom nicht in Richtung der Quelle fließt...

Allerdings sind wir dann schon sehr nah bei der Lösung die nic vorgeschlagen hat. Mit dem Unterschied, dass du hier selbst zwischen den Quellen umschalten kannst und das nciht implizit über die SPannung tust.

Ich habe keine Ahnung, aber ich werfe mal eine Idee in den Raum:

Ein Kondensator (ausreichend groß, je nach Verbraucher) zwischen Schalter und Verbraucher.

Dann müssten die Akkus aber so ausgelegt sein, dass sie eine höhere Spannung liefern als das Netzteil, oder?

Tatsächlich habe ich das sogar installiert

Ich denke auch der Code und villt nette Hinweise auf die nötigen Libs sollte reichen ^^

Wenn ich mich für deine Arbeit interessiere würde ich auch nur den Code lesen und nicht versuchen selbst auszuführen ^^

(Disclaimer: Ich werde in nächster Zeit nicht reinschauen )

Interessante Idee Also quasi eine Master-Slave-Schaltung ^^

Python, hat er im Titel geschrieben.

Bei Python würde man dafür für gewöhnlich eine Lambda-Funktion verwenden

Ich denke schon, dass es ein schöneres API-Design ist, die Dinge die relevant sind von vorne herein einzubauen...

Die UID wird vom Protokoll mitgesendet, in den C#-Bindings ist dadurch das Bricklet verfügbar das den Callback ausgelöst hat. Ich war tatsächlich gerade verwundert zu sehen, dass das in Python nicht der Fall ist.

Durch eine Anpassung der Binding-generatoren müsstest du an diese Informationen kommen. Da diese Änderung potenziell inkompatibel zur alten Version der Bindings ist weiß ich nciht wie viel Lust TF auf diese Änderung hat. Möglicherweise findet man aber auch einen abwärtskompatiblen Weg.

Also grundsätzlich wird das wohl funktionieren, dennoch fasse ich die beiden "aber"s nochmal zusammen:

1. Es kommt darauf an was du am Ende machen willst (Temperatur auslesen und auf nem Display ausgeben -> passt; Viele Dinge berechnen, nebenbei Werte abspeichern und umfangreiche Menüfürhung mittels 3 Displays und 4 EIngabegeräten -> das wird eher eng)

2. Vermutlich wird es schwerer sein die Entwicklungsumgebung für Firmwareentwicklung aufzusetzen. Das hängt aber auch von deinem Background ab. Wenn du eh lieber FWs in C schreibst, dann ist das was für dich ^^

Mein log war leider zu sparsam... da war nichts weiter drumherum. Allerdings habe ich eine Vermutung, es könnte der typische Fehler gewesen sein:

Zwischendurch war mein brickv connected, falls dieser die Callbacks ausgeschaltet hat und deine Bindings die Callbacks nutzen war das das Problem.

Ich tu einfach so als wäre das nie passiert, falls es jedoch wieder vorkommt versuche ich dir einen besseren Bug-Report zukommen zu lassen.

Ist der Quellcode deiner Bindings zufällig schon irgendwo gehostet? (github oder Google Code o.ä?)

Ich bin im Moment aber eh noch mehr im Testbetrieb, muss mir noch überlegen wie und wo ich am Ende die historischen Daten speichern will. RRD-Persistency scheint ja eine feine Sache zu sein, allerdings muss ich mich hier noch schlau machen, wie ich dann selbst an die Daten herankomme ^^ Offenbar ja nur über rrd4j... und geht das dann auch Parallel zum Logging-betrieb? ^^ Ein wenig ist hier also noch zu tun und herauszufinden

Ich glaube der Link zu deinen Bindings im Blog ist kaputt...

edit: Konkreter: in deinem blog-artikel unter HOME geht der Link zum download nicht.

DIe Links zu den beiden deb-Paketen (anderer Artikel) funktionieren.

Ich werde diese jetzt ausprobieren...

edit2: Davon abgesehen läuft es offenbar super. Ich kann auf die Sensoren zugreifen

edit3: Gerade nach etwas Herumspielen waren plötzlich ein paar Werte nciht mehr zu sehen... im Log fand sich folgendes:

21:01:40.688 INFO  o.o.c.s.AbstractActiveService[:201]- Tinkerforge Refresh Service has been shut down

Keine Ahnung was passiert ist ^^

Ich werde OpenHAB jetzt selbst einmal ausprobieren und dazu deine Bindings nutzen. Falls dabei Fragen oder Feedback aufkommen sollten werde ich mich hier melden.

Viele Grüße

Jan

Bleibt die Frage warum die Verbindung nicht zurückkehrt...

@jan: Ich glaube gelesen zu haben, dass die Verbindung die du hier betreibst übers Internet läuft. Es handelt sich bei dem fatalen Disconnect nicht zufällig um den 24h-disconnect des ISP? Genauer gesagt der 24h-disconnect des Stapels den du versuchst zu erreichen?

Dabei würde sich nämlich dessen IP ändern... wenn du nur per Hostname die Verbindung aufbaust, dann kann ich mir vorstellen (ich weiß es nciht sicher), dass beim Reconnect der Hostname nicht neu aufgelöst wird und somit fortan versucht wird die Verbindung zur falschen IP aufzubauen.

Das wäre natürlich nur eine Erklärung wenn sich die IP-Adresse geändert hat...

Ich weiß noch immer nicht was der timeout mit dem Reconnect zu tun haben soll. Da möge TF intervenieren, wenn ich hier Unsinn verbreite, aber der Timeout bezieht sich nur auf die Zeit die vergeht bis ein Getter abbricht und eine TimeoutException wirft anstatt den Rückgabewert zu liefern. Bei 20 Sekunden ist er einfach nur geduldiger.

Das Reconnecten zum Stack ist davon vollkommen unabhängig und wird gemacht sobald die Verbindung weg ist, wird aber nicht vom Timeout begrenzt o.ä.

Zur Ursprungsfrage: get_auto_reconnect sagt dir, ob grundsätzlich versucht wird die verbindung wieder aufzubauen.

Um welche Sprache ging es hier nochmal? Dann würde ich einmal in die BIndings schauen, um zu sehen ob dort das Verhalten ein anderes ist als das was ich aus C# gewohnt bin

Ich nutze Windows, insbesondere weil ich auch viel mit meinem Rechner zocke.

Habe noch ein Backtrack-Linux auf nem USB-Stick bei mir, nutze ich aber eher selten ^^

Beim Hardware Hacking Kit haben wir leider gerade Lieferschwierigkeiten zum ungünstigsten Zeitpunkt...

Da war wohl Heise schuld ^^

Euer Kit war ja nen Tag lang oder so der Headliner auf heise.de

ah okay... dann bin ich zumindest nicht total bedeppert ^^ danke für die aufklärung nic

Ich dachte

1. der timeout wäre in Millisekunden anzugeben

2. der timeout würde sich auf die Zeit beziehen die zwischen Anfrage und Antwort vergehen darf bevor eine TimeoutException geworfen wird...

Das würde aber bedeuten, dass du eigentlich mehr Fehler bekommen müsstest, weil 20 ms weniger sind als 2500 ms (default)...

Was ist denn ein ASCII-Interface?

Meinst du soetwas hier: http://www.tinkerunity.org/forum/index.php/topic,1578.0.html ?

Viele Grüße

Jan

Der connect sollte intern wohl eine kleine Wartezeit einbauen

Besser blockieren bis alles fertig ist. Offenbar gibts da ja eine gewisse Portion Nebenläufigkeit die fertig sein muss damit weitere Aufrufe funktionieren.

Das ist ja cool... ich musste wirklich suchen um herauszufinden wo dieser sinnvolle Text drumherum herkommt

Ich bin dafür die Timeline beizubehalten, aber einfach die Zeiten zu streichen...

SO eine Art semipriorisierte Liste.

Finde ich wirklich gut.

Ich denke solche Integrationen in bestehende Frameworks sind das was TF langfristig auch voranbringen wird.

Ich werde mir langfristig auch eine Plattform suchen müssen auf der ich dann anfange meine WOhnungsinternen Messwerte usw zu verwalten ^^

Da das bestimmt für einige Luete interessant ist hier die Standard-Frage:

Möchtest du das vielleicht auch im Wiki dokumentieren? Da geht es weniger schnell unter als im Forum.

Viele Grüße

Jan

Ich denke einen "non-intrusive-mode" im Brick-Viewer kann man schon gebrauchen. Eben mit Hinweis, dass das nicht so hochwertige Daten sind (gerade was kurzfristige Änderungen auf den IO-Bricklets betrifft).