Jump to content

TinkerForge Cloud


Ingenieur

Recommended Posts

Einen Vorteil gibt es:

Der Zugriff von aussen geht einfacher. Wenn man Komponenten an mehreren Standorten hat, kann man ohne Routerkonfiguration darauf zugreifen.

 

Ich selbst nutze VPNs, aber das ist mehr Soft-/Hardwareaufwand verbunden.

 

Die Frage ist, wie die Cloudanbindung gemacht ist. So geschlossen, dass man ohne Internet auf dem Schlauch steht, oder eben so transparent und als "add-on" konzipiert, dass man auch lokal kommunizieren kann.

 

 

Der Loetkolben

Link to comment
Share on other sites

@jgmischke

 

Es ist einfacher. Es geht nicht um den Server, sondern um den Cloudservice.

 

Wie sollen die Daten von einem Brick/let auf den managed Server kommen?

a) Ein lokaler Raspberry pumpt die Daten da hoch oder baut einen VPN Tunnel auf.

D.h. Serverkenntnisse sind notwendig inkl. Pflege.

b) die Bricks haben ein paar Byte Code und pumpen die Daten in die Tinkercloud, wo du sie per Software abholen kannst.

 

Das ist der Punkt. Es geht nicht um den Server im Internet, sondern  um den Weg dahin. ;-)

 

Damit mich keiner falsch versteht: Es bin KEIN Freund von fremden Clouddiensten, aber viele User und Programmierern koennen nichts anderes, bzw. die Kosten eines eigenen Servers sind hoeher und den meisten Anwendern ist Datensicherheit total latte. (Bis die erste Cloud-Microwelle in der Nacht die Kueche aufheizt)

 

BTW: Bei einer Tinkerforgecloud kann ich mir aber vorstellen, dass die Daten und der Datenfluss weitgehend geschuetzt und fuer den Programmierer nachvollziehbar ist.

 

 

Der Loetkolben.

Link to comment
Share on other sites

@jgmischke

 

Ich würde nicht alles zu einer Cloud-Dienst machen. Die Logik des Kontrollers kann weiter auf dem Red Brick/Raspberry Pi/usw. laufen. Meiner Meinung nach soll so eine Cloud-Dienst hauptsächlich für die Kontrolle der laufenden Systeme benutzt werden. Selbstverständlich, will einer auch die Logik der Anwendung zu der Cloud schieben, soll auch die Möglichkeit gegeben werden.

 

Vorteile:

- Konsistenz der Schnittstellen bei den eventuellen Änderungen

- Kontrolle der laufenden Systeme

- Kein Red-Brick notwendig, wenn man entscheidet für die Logik in der Cloud (-70 Euro in Budget des Projektes)

- keine Sorge bei den Verbindungen über 3G/4G

 

Und überhaupt, wenn die TinkerForge Kollegen weiter das Paradigma des OpenSource verfolgen, stellen sie auch die Quellen der Cloud zur Verfügung. Dann kann man bei Bedarf den Weg des Benders aus Futurama gehen: “I'm Going To Build My Own Theme Park With Blackjack and Hookers”.

 

Viele Grüße,

Kirill

Link to comment
Share on other sites

Also ich bin kein Freund von diesem Cloud Gedöns. Alles Marketinggeschwurbel zum Geldverdienen.

OK. Um seine lokalen Werte da gespiegelt abzulegen ja.

Aber das muss völlig losgelöst von den lokalen System funktionieren.

Schon garnicht irgendwelche Logiksachen auslagern.

Dann stehst du sofort auf dem Schlauch wenn deine Internetverbindung klemmt oder der Clouddienst deines Vertrauen offline oder gehackt ist.

 

Ich habe bei uns im Betrieb (Stahl & Walzwerk) die Programme für die Produktionsdatenerfassung im Walzwerk und bei den Drahtwerken geschrieben.

Schon da habe ich von Anfang an (2001) die Übertragung der Daten komplett vom Waageprogramm abgekoppelt. Das Waageprogramm läuft komplett als lokale Insel und schreibt seine Daten in eine lokal auf dem Rechner befindliche Datenbank.

Ein 2. Programm ,das nur für den Datenabgleich da ist, überträgt die Daten in die große Datenbank auf unserem Server. Der steht auch bei uns in der EDV und nicht in einer Wolke im Internet.

Wenn mal die LAN Verbindung klemmt oder der Server nicht erreichbar ist, aus welchem Grund auch immer, stört das die Waage überhaupt nicht und die Daten sind auch nicht weg , da ja lokal geschpeichert. Sobald der Server wieder erreichbar ist, werden alle Daten hochgeschaufelt. ;D

 

Noch dazu muss man beachten das man seine Daten in der Cloud komplett aus der eigenen Hand gibt und nicht garantieren kann, das niemand sich diese unter den Nagel reist. Und das Marketinggewäsch von wegen "Ihre Daten sind bei uns absolut sicher!" ist eben nur ein Verschprechen. Wer das glaubt......

Link to comment
Share on other sites

Es kostet Geld. Für den Betreiber: Server, Entwicklung, Wartung. Das muss wieder eingespielt werden oder als "Marketing" abgeschrieben.

 

Meine Datenbank ist jetzt nach 5 Jahren mit 25 Mio. Werten ist jetzt knapp 1GB groß (15 Sensoren).

Wenn das ein paar 100 Nutzer machen kommen schon eine Menge an Daten zusammen.

 

Klar wäre es bequem, direkt in der TF-API einen Befehl send2Cloud(apiKey, deviceID, value) zu haben, aber es müsste auch eine lokale Zwischenspeicherung möglich sein, falls das Internet mal ausfällt.

 

Zur Sicherheit: Systemkritische oder Sicherheitsrelevante Dinge würde ich jetzt auch nicht darüber steuern / speichern wollen.

 

Link to comment
Share on other sites

@FlyingDoc

 

Keine Frage, dass man manchmal das "Cloud Gedöns" ohne Sinn und Verstand verwendet. Nur weil es auf einmal zum Trend geworden ist. Aber wenn das Nutzen von solcher Lösung mehr als Kosten bzw. Risiken ist?

 

Man hat mich wahrscheinlich falsch verstanden. Ich persönlich brauche so ein System nur für die Überwachung und Kontrolle. Von solchem System würde ich ein Dashboard mit der allgemeinen Information der Bricks erwarten und ein Paar Wartungswerkzeuge (ssh, telnel usw.)

 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...