Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation since 11/11/19 in all areas

  1. Der lokale Netzbetreiber selbst beschränkt auf 11kW in Summe? Oder meinst du wegen der Förderung? Es sind zwar nur 11kW Wallboxen förderfähig, aber man kann sich theoretisch 2stk fördern lassen und die auch gleichzeitig nutzen. Zum Thema Lastmanagement zwischen zwei Ladepunkten: Das ist das erste Feature welches wir nachreichen werden, da die Nachfrage danach so groß ist!
    3 points
  2. Der aktuelle Stand ist, dass wir alle daran arbeiten, die vorbestellten Boxen zu bauen und zu verschicken. Wenn da Zeitlücken sind arbeite ich an der Firmware. Voraussichtlich wird das erste größere Feature, dass ich einbaue eine Zeitschaltung, danach geht es an die Implementierung des Lastmanagements. Da gibt es aber noch viele Entscheidungen zu treffen, wie das genau funktionieren wird, z.B. ob man gleich auf OCPP geht, oder erst eine Implementierung schreibt, die nur zwischen unseren Boxen funktioniert. Auf jeden Fall wird das aber eine reine Softwareimplementierung und die Boxen werden übe
    2 points
  3. Der Stromzähler benötigt einen permanenten Anschluss aller drei Phasen um sich selbst mit Strom zu versorgen. Wenn die Last (Fahrzeug) nur eine Phase nutzt ist das kein Problem. Der interne Kabelsatz ist identisch. Das heißt du musst den Klemmenblock der Smart entfernen und dafür dann den Zähler einbauen. Dann fehlt dir das RS485 Bricklet und die Verkabelung zum Zähler. Die Verkabelung sollte man selbst herstellen können. Als letztes ist die interne Schutzabdeckung noch eine andere bei der Pro, da der Zähler ja einen Ausschnitt benötigt. Diese wollen wir aber genau zu diesem Zweck als
    2 points
  4. Hallo Photon, rein technisch bieten die Boxen aktuell kein RFID. Es ist aber platztechnisch möglich ein NFC Bricklet anzuschließen (soeben). Ich denke wir werden bei Zeiten das mal vorstellen.
    2 points
  5. Hallo Tamino, schön zu sehen dass hier weitere "Franken" im Forum aktiv sind 🙂 grüsse aus Ansbach Stefan
    2 points
  6. Hallo riro ich habe das Outdoor Weather Bicklet gemeinsam mit dem TH-6148 Sensor von Tinkerforge im Einsatz. Der Sensor liefert Temperatur & relative Luftfeuchte und einen String wann der letzte Datensatz empfangen wurde. Wenn Du die Outdoor Weather Station hast, dürfte das vorgehen ähnlich sein, nur dass diese mehr Daten übermittelt als der TH-6148 Sensor. Als erstes muss Du den Sensor Identifier (für den TH-6148) oder den Station Identifier (für die WS-6147) ermitteln. Das kannst Du über den Brickviewer oder du legt ein entsprechendes „String-Item“ mit dem passen
    2 points
  7. Hallo Martin, Leider nicht. Das sieht der Standard nicht vor. Das benötigt dann PLC. Es Lösung dafür gibt es aber oftmals die Möglichkeit über die Cloud des Fahrzeugs zu gehen um dann darüber an den Ladezustand zu gehen. EVCC tut so etwas zum Beispiel. Wir arbeiten gerade mit denen zusammen das unsere Box auch unterstützt wird. Rein elektrisch gibt es nichts was das behindern würde. Die Box schaltet technisch ja nur ein Schütz, welches die Stromversorgung zum Fahrzeug herstellt. Strom kann technisch dann in beide Richtungen fließen. 11kW einstellen lassen und es is
    1 point
  8. Es muss leider jeder Master einzeln (nicht im Stapel mit anderen Bricks) geupdated werden. Die Updates sind jedoch kein MUSS. Nur wenn neue Funktionen des Masters verwendet werden sollen, bedarf es eines Updates. Ich belasse meine Wetterstation bei aktuellen Updates für die Bricklets (Over-The-Air) und die Master laufen noch stabil mit Firmware 2.0.
    1 point
  9. Hello. Has anyone tried integrating IMU Brick 2.0 and GPS Bricklet 2.0? My goal is to get the accelerometer data timestamped in GPS time system. Thanks if anyone can share ideas/experience.
    1 point
  10. 230V an L1 und N - funktioniert. PE (Grün/Gelb - Schutzleiter) dann aber bitte auch anklemmen! USB-C am ESP32 wird so halb funktionieren. Da dann nur der Steuer/WLAN Brick Strom hat, kannst du zwar das WLAN einstellen und testen, aber der Wallbox-Teil der Weboberfläche wird mangels EVSE Bricklet (weil stromlos) ausgeblendet sein. Ist aber ohne Auto sowieso langweilig bzw. nicht spannender als die Bilder hier: https://www.tinkerforge.com/de/blog/warp-charger-eine-tour-durch-die-software/.
    1 point
  11. Dafür gedacht ist dieser nicht, da wir den nicht nach draußen führen. Rein elektrisch betrachtet handelt es sich aber um ein Freigabesignal.
    1 point
  12. Hallo Jkw, bei der neusten Firmwareversion 1.1.0 wird nicht direkt der RSSI Wert, aber die WLAN Qualität angezeigt (wie beim Smartphone auch über "Balken"). Über unsere HTTP und MQTT API kommt man an den RSSI Wert dran (siehe "wifi/state" auf https://www.warp-charger.com/api.html) VG Bastian
    1 point
  13. Vielen Dank für deine Arbeit, ich freu mich schon auf meinen warp pro. Aktuell denke ich sogar schon über den zweiten nach. Dazu habe ich eine Frage zum lastmanagement: ist das dann nach Implementierung auch bei der warp smart verfügbar, oder ist man in jedem Fall auf die pro angewiesen?
    1 point
  14. Wir bieten ja absichtlich das modulare Konzept, damit so welche Dinge möglich sind. Allerdings können wir nicht alle erdenklichen "Mods" ab Werk liefern. Das heißt wenn ihr noch weitere Löcher im Gehäuse benötigt, dann müsstet ihr die selbst bohren. Was wir euch aber anbieten können ist, dass wir euch gelaserte Abdeckplatten bieten die für die Smart Wallbox sind (ohne Zählerausschnitt) aber die dennoch die Befestigungslöcher für das RS485 Bricklet bieten. Schreibt uns dazu bitte per Mail an. Habt aber bitte Verständnis dafür, dass wir aktuell zusehen alle 5m Wallboxen den Kunden zuzuschic
    1 point
  15. Das sieht schon mal gut aus! Kannst du testweise nochmal die 2.4.14 runterladen? http://download.tinkerforge.com/tools/brickv/macos/brickv_macos_2_4_14.dmg Ich würde dann erwarten, dass bei Graphics Card ein Yes steht.
    1 point
  16. Das ist erwartet. Mosquitto erwartet bei "require_certificate true", dass sich der Client (tinkerforge_mqtt in diesem Fall) per Client Zertifikat ausweißt. Das tut tinkerforge_mqtt aktuelle nicht. Das müsste man tinkerforge_mqtt erst beibringen, damit du neben ca.cert auch client.crt und client.key angeben könntest.
    1 point
  17. Im Debug-Log ist auffällig, dass die Bindings TLS 1.3 sprechen, du Mosquitto aber auf TLS 1.2 betreibst (da kannst du nicht so einfach auf 1.3 wechseln, das gibt es erst ab Mosquitto 1.6 und Raspberry Pi OS liefert noch die 1.5.7 aus) Als Schnellschuss: Teste mal mit der angehangenen Bindings-Version, in der ich TLS 1.2 erzwungen habe. tinkerforge_mqtt_bindings_2_0_14_rc2.zip
    1 point
  18. Moin, Das kannst du unter Configuration -> Things -> das IO-16-Bricklet einstellen. Da gibt es über den Namen einen blauen Button, mit dem du die Thing-Einstellungen öffnen kannst. Darin kannst du, genau wie mit Brick Viewer, die Ports konfigurieren. Das liegt daran, dass die Bindings sich nicht darauf verlassen, dass die Konfiguration unverändert ist, wenn das Bricklet neu auftaucht oder openHAB neustartet o.Ä. und deshalb alles neu setzt. Das ist noch auf der Agenda. Ich bin leider immer noch mit einem anderen Projekt beschäftigt *hust*. Wenn da der Release-Stre
    1 point
  19. Hallo sihui danke für den Link der Dezember Video Präsentation der neuen Openhab3 Version. Ich habe mir das Video angesehen und es unumstritten dass die neue MainUI sehr viele Möglichkeiten bietet, die das Leben in Openhab erleichtern wird. Ich werde auf jedem Fall die neue MainUI testen, kann durchaus sein, dass ich dann auf Text-Config-File verzichten werde. Ein NOGO für mich wäre, wenn ich keine Rule als Text-File anlegen könnte, denn das wäre für mich ein absoluter Kontrollverlust. So wie ich das verstanden ist dies aber in Openhab3 weiterhin möglich. Es lebe die V
    1 point
  20. Dann schau dir mal die neue MainUI in openHAB3 an. Du wirst keine Textdateien mehr mögen. Und auch das stetige Argument, "wenn ich viele gleichartige Things anlegen möchte geht das nur über Textdateien flott" ist ad acta gelegt: das geht jetzt auch über die MainUI und zwar ähnlich flott. Ich empfehle mal die Aufzeichnung des virtuellen openHAB Meetups v. 05.12. anzuschauen, ab ca. 26:30 min geht es los mit der Vorstellung der MainUI.
    1 point
  21. Sehr komisch. Da habe ich keine gute Idee zu. Das initiale Programm sollte einfach funktionieren, abgesehen von den 4 Writes direkt nacheinander. Für mein Verständnis: Aus Brick Viewer heraus funktioniert alles wie erwartet. Wenn die Anfrage gesendet wird kommt eine passenden Antwort darauf. Wenn ihr das aber aus eurem Programm heraus macht kommt keine Antwort. Wenn aber euer Programm läuft und ihr parallel dazu in Brick Viewer die Anfrage sendet, dann kommt eine passenden Antwort in eurem Programm und in Brick Viewer an. Habe ich das so richtig verstanden? Was passiert wenn Bri
    1 point
  22. Das Beenden müsste dein Programm selbst machen. Zum Beispiel den Wert time.time() beim Start des Programm speichern, dann in der Schleife mit dem aktuellen time.time() Wert vergleichen und nach 8h (28800s) das Programm beenden. Das Starten kannst du über den Scheduler machen. Dort den Cron Modus wählen mit "0 8 * * *", damit das Programm jeden Tag um 8 Uhr gestartet wird.
    1 point
  23. Das ist ein Python 2 vs 3 Problem. Du verwendest auf deinem PC Python 3, auf dem RED Brick aber Python 2. In Python 2 hängt der Typ einer Division von den Operanden ab: 2 / 3 ergibt eine Integer-Division 2 / 3.0 eine Float-Division. In Python 3 macht der normale Divisions Operator / immer eine Float-Division und für eine Integer-Division muss man // verwenden. In deinem Fall betrifft dieser Unterschied die alpha Berechnung: alpha = (count*360)*10/1000 Alle Operanden darin sind Integer, dadurch passiert dort eine Integer-Division, obwohl du eine Float-Division erwartest
    1 point
  24. Du benutzt das Authenticate falsch, den setInputValueCallbackConfiguration-Aufruf (und alles weitere was erst passieren soll, wenn die Verbindung steht und authentisiert ist) musst du in das returnCallback des authenticate-Aufrufs packen.
    1 point
  25. Error 31 is "Timeout". The most common cause for this is that you used the wrong UID in the example. Are you sure it's error 31? Error 13 is "Connection Failed" that could be caused by wrong IP address or port configuration. The RED Brick does not used the WebSocket port configured on the Ethernet Extension itself. For the RED Brick you need to configure the WebSocket port on the RED Brick itself: Brick Viewer > RED Brick > Settings > Brick Viewer > Web Socket Port.
    1 point
  26. Also, so wie du Promise verwendest kann das nicht funktionieren. Du legst ein leeres device_promises Array an, und im Prinzip rufst direkt danach Promise.all auf ein leeres Array auf. Dieses Promise ist natürlich sofort erfüllt, denn die Enumerate Callbacks kommen erst danach an. Damit der Ansatz funktioniert musst du vor dem ipcon.enumerate() Aufruf wissen wie viele Devices vorhanden sind und die Promises vorher anlegen und nicht erst im Enumerate Callback, denn dort ist es zu spät. Wenn du nicht weißt wie viele Devices vorhanden sind kannst du das über einen Timeout lösen. Die Annahme d
    1 point
  27. Hi, The RS485 Extension only works with a Master Brick (that's why it's called Master Extension ;) ). So at least two Master Bricks, two RS485 Extensions and one IMU Brick are required. The Master Bricks have to be bottom most in the stack, for example RS485<---------->RS485 IMU Master<-->PC Master should work.
    1 point
  28. Hi! Ich habe die Javascript Bindings noch nicht verwendet, aber mir scheint, dass Du erstmal nichts anderes machen willst, als die im IPConnection Example Code ausgegebenen Devices in ein Array zu schreiben, und in deinem Programm darauf zu warten, dass dies Array befüllt ist. Kommst Du vielleicht weiter, wenn Du das Beispiel entsprechend erweiterst?
    1 point
  29. Moin, (Disclaimer: Bin kein JavaScript-Experte) Das Problem ist sogar noch etwas komplizierter, da du ja nicht weißt, wie viele Bricks/Bricklets vorhanden sind, das heißt rein technisch weißt du nicht, wann du fertig bist mit dem Warten auf die enumerate-Callbacks. Du kannst aber so Kriterien wie "ich weiß es sind genau X Bricks/Bricklets" oder "wenn nach 0.5 Sekunden kein neues Callback kam bin ich fertig" oder einfach "Ich warte eine Sekunde auf Callbacks" o.Ä. verwenden, das ist typischerweise gut genug. Ein Ansatz der dein Problem löst wäre, wenn das Auslösen mit .enumerate(
    1 point
  30. Man soll ja nichts versprechen, aber ich bin mal optimistisch und behaupte dieses Jahr noch.
    1 point
  31. Ja, das ist leider so. Ich habe dem Update Dialog jetzt einen Hinweis hinzugefügt, dass der Prozess durchaus bis zu 2 Stunden dauern kann.
    1 point
  32. ACHTUNG: Arduinos mit AVR-Mikrocontroller (z.b. der Arduino Uno und Mega) haben einen Logikpegel von 5V und brauchen deshalb einen Pegelwandler zwischen dem Arduino und dem Bricklet. Bricklets haben einen Logikpegel von 3,3V. Edit: Hier die offizielle Dokumentation. Moin, Nachdem es in letzter Zeit häufiger Kundenanfragen danach gab, Bricklets direkt mit einem Mikrocontroller zu verwenden, habe ich die letzten Monate entsprechende Bindings entwicklet. Die erste Beta der C/C++ Bindings für Mikrocontroller, mit denen Koprozessor-Bricklets direkt von z.B. einem Arduino über SPI ges
    1 point
  33. Du bist noch in openHAB unterwegs? Dann kannst du dir diesen Post mal ansehen.
    1 point
  34. Moin, Ich bin bisher noch nicht dazu gekommen, muss gerade ein anderes Projekt priorisieren. Ich werde aber diese Woche noch einen Tag für diversen Kleinkram Zeit haben, da sollte auf jeden Fall die DC-Brick-Rule rausfallen. Erik
    1 point
  35. Fixes have been released as part of MQTT bindings version 2.0.10.
    1 point
  36. Jupp, der Brick Viewer sollte schon fleißig Update-Meldungen erzeugen. Die Bindings sind angehangen. tinkerforge_c_bindings_2_1_28_barometer_i2c.zip
    1 point
  37. Nein, das Temperatur Bricklet setzt die Geschwindigkeit nur vor seiner Abfrage kurz runter und danach wieder hoch. Nein, nur durch einen Reset des Bricklets. Unter der Prämisse, dass es nur das Temperature Bricklet ist, das den Bus lahmlegt sollte das nicht notwendig sein. Falls das Barometer das auch hinbekommt, kann man sich das natürlich nochmal ansehen.
    1 point
  38. Ist bei beiden der ERA-6AEB910V also 91Ohm. Auch hier zu sehen: https://github.com/Tinkerforge/industrial-dual-0-20ma-v2-bricklet/raw/master/hardware/industrial-dual-0-20ma-v2-schematic.pdf
    1 point
  39. Teste mal bitte die angehängt Version (siehe net40sn Verzeichnis). Ich habe hier gerade kein LabVIEW NXG zur Hand, aber diese Version lässt sich zumindest mit gacutil installieren. tinkerforge_labview_bindings_2_1_24_strong_name.zip
    1 point
  40. Hallo Tim (Teddy) danke für Dein Angebot bezüglich der „Taster-Abdeckungen“ In meiner aktuellen produktiven Openhab 1.9 Umgebung habe ich ein Bedienfeld mit einem LCD20x4 und einem Multitouch 3x4 Key-Pad. (siehe Bild unten, besteht aus Acryl 5mm, wurde mit einem Laser-Cutter bei einem Lokalen Acryl-Glas Handel hergestellt) Diese Bedienfeld-V1 möchte ich mit der Umstellung meines Prod-System auf OpenHab2 komplett neu aufbauen und aktuelle Tinkerforge Komponenten integrieren. Vom Aufbau würde ich wieder 5mm Acryl nutzen, die Bricklets würde auf einem Basis-UnterRahmen befesti
    1 point
  41. Hm, bei den Callbacks war das noch anderweitig kaputt, sorry dafür! Die angehangene Variante sollte funktionieren. tinkerforge_perl_bindings_2_1_25.zip
    1 point
  42. Moin, Beta 15 ist jetzt im Post oben. Das Outdoor Weather Bricklet funktioniert jetzt wie hier beschrieben: Außerdem habe ich das Problem mit der Bridge Selection gefunden, sodass jetzt keine Fehler mehr auftauchen, wenn man die in den Thing-Einstellungen editiert. Das heißt, dass man jetzt konfigurierte Bricks und Bricklets zwischen Brick Daemons (und damit auch Stapeln) verschieben kann. Im Moment führt das noch dazu, dass dann in der Inbox noch ein Thing zu viel auftaucht, das fixe ich in der nächsten Beta. Die Firmware-Update-Logik funktioniert jetzt über die Interfaces d
    1 point
  43. Port 4223 ist der normale TCP/IP Port. WebSockets laufen nicht über Port 4223, sondern über Port 4280. Dieser Port ist auch in allen Beispielen korrekt voreingestellt. Hast du das händisch auf Port 4223 abgeändert? Darüber hinaus musst du WebSockets erst in brickd aktivieren: https://www.tinkerforge.com/de/doc/Software/API_Bindings_JavaScript.html#id2
    1 point
  44. Moin, Das klingt seltsam, ich sehe mir das am Montag mal beides an. (Dann aber gleich mit der fertigen 2.5-Version, die soll angeblich am Sonntag erscheinen). Vor Weihnachten gibt es dann auch noch eine neue Beta-Version der Bindings.
    1 point
  45. Brick Daemon 2.4.1 mit den Änderungen fürs HAT ist jetzt veröffentlicht.
    1 point
  46. Moin, Ich habe das ganze hier reproduzieren können. Ich melde mich, wenn ich mehr weiß. Kannst du, wenn das Anstecken nichts tut, den RED-Brick mit dem Power-Knopf starten (Braucht so 2-3 Sekunden, der Knopf ist links neben der USB-Buchse) oder musst du dann das Kabel neu aus-/einstecken?
    1 point
  47. Es gibt zwei Varianten von Base58: https://en.wikipedia.org/wiki/Base58 Wir verwenden die Flickr Variante, die meisten Online Tools scheinen aber die Bitcoin Variante zu verwenden. 6DbKt8 dekodiert zu 0x31 0x10 0xb1 0xdc Ich kann auf Anhieb kein Online Tool finden, dass die Flickr Variante nutzt. Ich habe gerade ein kleines Python Script zusammenkopiert, dass die Flickr Variante dekodiert: $ python3 base58decode.py 6DbKt8 base58: 6DbKt8 decimal: 3702591537 hexadecimal: 0xdcb11031 bytes (little endian): 0x31 0x10 0xb1 0xdc $ python3 ba
    1 point
  48. Moin, Das klingt, als ob die Kamera etwas aus ihrem Sockel gerutscht ist. Hilft es, wenn du die Kamera (vorsichtig) wieder in den Sockel drückst?
    1 point
  49. Du kannst das einfach dranstecken, der Brick Daemon auf dem Raspberry Pi findet sowohl HAT und daran angeschlossene Bricklets, als auch Bricks, die per USB angeschlossen sind. Du kannst dann mit einer IP-Connection beides steuern, so als ob alles am HAT oder per USB angeschlossen wäre.
    1 point
  50. Hallo zusammen, ich würde gerne mein neues Projekt vorstellen. Ich habe mich mit 4 Temperatur/Luftfeuchte Sensor TH-6148 ausgestattet und sie in der Wohnung + Balkon verteilt. Temperaturen und Luftfeuchtigkeit stelle ich auf einem Grafana Dashboard dar. Folgende Hardware habe ich genutzt 1 Master Brick 4 Temperatur/Luftfeuchte Sensor TH-6148 Rasberry Pi 2 Software Ein Script mit golang, welches die Daten ausliest und als Metriken ausgibt (https://github.com/danielgrewing/go-tinkerforge) Prometheus für die Sammlung der Daten (https://prometheus.io/) Grafana als Dashboard (htt
    1 point
×
×
  • Create New...