Equinox

Hallo

Für Dauerbetrieb über Monate und länger sind die TF Teile m.E. nicht geeignet, außer man schließt passende Versorgungsbatterien an

Das sehe ich auch so, deshalb ja auch dieser Thread mit Verweis, was technisch möglich ist. Vielleicht hat ja einer der TF-Jungs dadurch einen Einfall oder sieht eine Möglichkeit, wie das in zukünftige/aktuelle TF-Produkte einfließen kann.

Hallo,

das "Industrial Quad Relay" Bricklet schaltet bis zu 30V mit 1,2A. Sollte also gehen.

Hallo,

Quatsch  Der Verbrauch liegt bei 10mA gegenüber den 110/23mA der WIFI-Ext.

Der Vergleich war ja auch nicht mit der WiFi-Extension gedacht, sondern mit der Technik aus dem verlinkten Artikel bzw. "ganz allgemein".

Gibt es schon: der RemoteBricklet hat einen Transceiver Baustein damit könnte der RemoteSwitch auch empfangen.

Klar, aber hier brauche ich noch einen Master + Stromversorgung. Und ob man damit mit ein paar Batterien über ein Jahr versorgt ist, weiß ich nicht, vmtl. aber nicht.

Es sei wir lösen es mit dem RED-Brick 

Der RED Brick ist zwar eine klasse Sache, aber dafür schon aus Kostengründen nicht geeignet.

Hallo,

du meinst, der Lüfter soll über die selbe Stromquelle wie der TF-Stapel versorgt werden?

Dazu fallen mir nur das "Analog Out" Bricklet (das vmtl. nicht reichen wird, da es nur 5V und 24mA liefern kann) oder das "Step-Down Power Supply" ein. Letzteres hat eine Ausgangsspannung von 5V (max. 3A). Wenn dein Lüfter also weniger als 15W Leistung hat, müsste das gehen, wenn du die Spannung z.B. mit erwähntem Teil auf 12V wandelst.

Hallo,

genau wie du gesagt hast:

Akku/Power Supply -> Dual Relay Bricklet -> Lüfter

Wenn du das noch ein bißchen erweitern möchtest, dann kannst du z.B. mit einem Voltage/Current-Bricklet die Spannung am Akku messen und falls sie zu niedrig ist, den zweiten Anschluss des Dual Relay Bricklet dazu verwenden, zwischen Akku und Power Supply umzuschalten.

Wirklich cool 

Bluetooth hat im Vergleich zu der im Artikel erwähnten Technik eine viel geringere Reichweite.

Müssen nicht unbedingt neue Bricklets sein. Es würde ja ein "Sende-/Empfangsmodul" reichen. D.h., die Bricklets werden an dieses Modul angeschlossen, das die Stromversorgung und die drahtlose Kommunikation übernimmt. Auf den Master wird ebenfalls so ein Modul für die Kommunikation gesteckt. Aus Master- und Programmierersicht sollte dies vollkommen transparent sein, d.h., es sollte keinen Unterschied machen, ob ein Bricklet direkt per Kabel an einem Master hängt oder über dieses Modul.

Hallo,

es gab ja hier schon öfter die Diskussion, wie man Bricklets möglichst einfach, kostengünstig, mit großer Reichweite und geringem Stromverbrauch anbinden kann. Wifi-Extension + Masterbrick hat eine zu geringe Reichweite und ist zu teuer, die Chibi-Extension gibt es im Moment nicht und hat vmtl. auch einen zu hohen Stromverbrauch.

Evtl. gibt es dafür eine Lösung:

http://www.angelblocks.com/index.php/technical-articles/41-angelblocks-radio-technology (Der Artikel enthält auch einen Link zum "Erfinder" der Technik).

Umgesetzt werden soll es u.a. mit diesem Kickstarter-Projekt:

https://www.kickstarter.com/projects/1630453569/angelblocks-smart-wireless-building-blocks-for-sma

Wäre diese Technik nicht auch was für Tinkerforge? Ich fände es super, wenn man die Bricklets drahtlos über große Entfernungen ansprechen könnte und diese dort nur mit einer Batterie über einen langen Zeitraum mit Strom versorgt werden  könnten.

Hallo,

super, danke für die Infos!

Hallo,

guter Tipp, danke. Werde ich mal ausprobieren, wenn ich meinen RasPi von meinem Repeater trennen muss.

Aber zurück zum eigentlichen Topic:

Empfehlungen/Erfahrungen für die Anbindung einer IP-Cam mit Java?

Hallo Loetkolben,

ich habe einen "Edimax EW-7811Un super Mini Adapter". Soll einer der beliebtesten WLAN-Sticks für den RasPi sein, aber im Moment nicht im Einsatz.

Gibt es noch irgendeine Empfehlung für eine IP-Cam, die per Java "ansprechbar" ist?

Hallo Loetkolben,

ich hatte das Problem, dass der RasPi nach spätestens 3 Tagen die Verbindung zum WLAN-Access-Point verloren hat und nicht wieder automatisch aufgebaut hat. Ich habe es nicht näher analysiert, an was das lag, da ich, um an meinen TF-Stapel per WLAN zu kommen, sowieso einen Repeater benötigt habe. Den RasPi habe ich dann dort per Kabel angeschlossen. Das läuft sehr stabil (mehrere Wochen ohne Probleme).

Ist aber gut zu wissen, dass es beim RasPi und WLAN allgemein Probleme zu geben scheint.

Hallo,

wie gesagt fällt ein weiterer RasPi aus oben genannten Gründen weg.

Wie sieht es denn grundsätzlich mit der Möglichkeit aus, per Java/REST Fotos/Videos zu machen und zu speichern? Hat das schon jemand von euch gemacht? Geht des mit jeder Cam? Braucht man da spezielle Software?

Hallo,

weniger ersteres, da ich keine 2-Wege-Audioverbindung brauche und auch eine bessere Auflösung wäre nicht schlecht (VGA ist schon recht wenig), aber im Prinzip trifft es das. Die Frage ist nur, welche davon sind per (Java-)API ansprechbar und wie ist die Bildqualität? Hat jemand von euch sowas im Einsatz und kann es empfehlen?

Preislimit: Gute Frage. Ich habe gehofft, dass man sowas schon für 40-60 Euro bekommt. Ich denke, mehr als 80 Euro würde ich nicht investieren.

Hallo,

Was ist mit einem PI+PiCam im gleichen Gehäuse

Würde vmtl. gehen, allerdings bräuchte ich dann einen weiteren RasPi, weil mein vorhandener dort bleiben muss. Das möchte ich aber nicht, da man diesen dann ja auch "pflegen" muss (ich möchte den Aufwand möglichst gering halten). Ich denke auch, dass dies vmtl. teurer kommt als "nur" eine Cam. Außerdem habe ich schlechte Erfahrungen mit RasPi und WLAN-Stick gemacht. Es sollte also wirklich eine WLAN-Cam sein.

Hallo,

Was spricht gegen RasPi + RaspiCam ?

Oder hast du am Standort nicht genug Platz, bzw. kein Strom?

Daran habe ich auch schon gedacht, aber wie gesagt, steht der RasPi "weit" weg vom TF-Stapel und auch vom zukünftigen Platz der Web-Cam. Die Web-Cam muss als zwingend per WLAN angebunden werden.

Hallo,

leider ist dort, wo die Kamera stehen soll, kein Rechner in der Nähe, es muss also per WLAN sein.

Die Idee ist aber nicht schlecht, ein "Zusatzprogramm" zu nehmen, das den Stream abgreift und auf das dann per Java/REST zugegriffen wird. Gibt es da Alternativen? Im Moment müsste das Programm auf einem RasPi laufen, sollte aber möglichst plattformunabhängig sein (Java).

Hallo,

ich bin auf der Suche nach einer guten und günstigen Web-/IP-Cam.

Sie sollte folgendes können:

• WLAN
  
• Gute Bildqualität bei Fotos
  
• Gute Bildqualität bei Videos (HD ready reicht)
  
• Ansprechbar über Java und/oder REST (d.h. HTTP-Request). Es sollte also möglich sein (vereinfacht ausgedrückt), in Java z.B. "getPicture()" oder "getVideo()" aufzurufen und dann macht die Kamera ein Bild oder ein Video und schickt es an das Java-Programm (oder eben per HTTP-Request).
  

Schön wäre auch, wenn sie "Pan-Tilt-Zoom" mit automatischem Motion-Tracking hätte, ist aber optional.

Kann da jemand was empfehlen?

(Hintergrund: Ich möchte ein Foto oder Video machen, wenn das TF-Motion Detector-Bricklet Bewegung erkennt.)

Warum ist es dann nicht eigenständig, nur weil ein Linux darauf läuft?

Ganz einfach: Die Leistung vom Brick ist einfach viel zu Viel. Ein atMega ist für mich eigenständig. Da die Leistung hier deutlich geringer ist. Bei den Geplanten RED Brick ist die Leistung aber mit dem eines PC vergleichbar. Zur Leistung zählt zum einen die CPU und zum anderen auch der Verbaute RAM.

Ich verstehe nur Bahnhof 

Was hat denn "Eigenständigkeit" mit der Leistung zu tun und vor allem, warum ist zuviel Leistung schlecht für die Eigenständigkeit? Abgesehen davon, dass mehr Leistung nie schadet, ist es gerade für die den standalone-Betrieb ein Vorteil.

Also ich verstehe dein Problem nicht.

Regarding authentication:

I think option 2 (For all communication) is the more basic and general approach. Having authentication not only for WebSockets but for the whole communication would increase security for the complete system.

OK, thanks for the explanation. Now, I understand 

I didn't think of the stack being connected to the localhost as I'm not using that kind of setup. But nevertheless, yes, in these cases it is a problem .

It'll just connect to localhost:4280 to connect to the brickd on your PC. And even if you change the port then it can just probe all ports.

What if the stack is connected via e.g. WiFi-Extension and no brickd is running on the localhost?

Hmm, still don't understand 

The JavaScript-Code from your fraudulent website may know the port (but even that can be changed as you said), but it doesn't know the IP-address of the stack or the brickd, right? So, how can it access my stack without knowing ip-address and port?

Sorry, I don't understand 

Why does a browser running on a PC somewhere in the Internet (e.g. Internet-Café) have access to my local network or brickd if I block all connections from outside?