Jump to content

mabri

Members
  • Gesamte Inhalte

    34
  • Benutzer seit

  • Letzter Besuch

Letzte Besucher des Profils

Der "Letzte Profil-Besucher"-Block ist deaktiviert und wird anderen Benutzern nicht angezeit.

mabri's Achievements

Newbie

Newbie (1/14)

  • Collaborator Rare
  • First Post
  • Conversation Starter
  • Week One Done
  • One Month Later

Recent Badges

0

Reputation in der Community

  1. auch eine Möglichkeit - denke für die Idee
  2. Das klingt ja schon mal gut! SOC - das geht über eine API des Fahrzeugherstellers, also hier nicht das Problem. ModBUS/TCP wäre ok. Das Einzige was cool wäre, wenn ein "Interrupt" gesendet werden würde, wenn Aktivitäten an der WB stattfinden - Pollen ist gut, aber nervig und unschön ;-) gruß Martin
  3. mabri

    Warp Charger / RFID-Tags

    Hallo, ist es möglich, dass der Charger einen (erkannten) RFID-Tag weiter meldet an eine Zentrale, die dann entscheidet, ob der Ladevorgang startet und mit welcher Leistung. Hintergrund: Ich plane eine firmeneigene Ladeinfrastruktur mit 7 Ladesäulen. Diese Ladesäulen sollen in das BMS (building management system) integriert werden. Ich stelle mir vor, dass ich damit die Begrenzung der TAGs pro Ladesäule umgehen kann, die Fahrzeuge anhand der ihen zugeordneten Tags priorisieren kann (Gast-Fahrzeuge vor Pool-Fahrzeugen vor MA-Fahrzeugen), zentral die Ladeprotokolle führen kann, weiß was die maximale Ladeleistung des Fahrzeugs ist, was sein SOC ist (ja nicht über den Charger), etc. Am jeweiligen Ladepunkt ist Ethernet und eben Strom (400V/32A) für Kommunikation und Ladeleistung vorhanden. Darüber hinaus müssen wir die Ladesäulen in soweit steuern, dass die die vom Netzbetreiber auferlegten Grenzwerte (Ladesleitung aus dem Grid << 7 x 22 kW) nicht überschritten werden und Abhängigkeit der vorhandenen PV- bzw. PV-Battery-Puffer nutzen - das spricht auch für eine zentrale Steuerung, da ja nicht nur der Bedarf der WB, sondern auch des restlichen Gebäudes eine Rolle spielt. Das alles soll hier nur als HIntergrund dienen. Wichtig ist nur: kann die WB (ein Ladepunkt) eine Anmeldung weiter reichen, also in den Dialog mit einer (von uns anzupassenden) Schittstellen-SW gehen, die dann eine Freigabe (oder eben nicht) und eine Ladeleistung vorgibt. Ich bin offen für alle Ideen und Vorschläge (nur keine Lösungen die den Einsatz einer fremden Cloud benötigen!) gruß Martin
  4. Danke Bastian, das ist genau das was ich befürchtet habe; Dann bleibt eigentlich als Alternative nur eine Spannungsversorgung mit 2 x 12 V AC aus einem Trafo mit Anzapfung, so dass ich für die Versorgung des Stacks mit 12 V (nach Gleichrichtung/Siebung <= 18V) und eben 24 V AC für die gesteuerten Systeme lebe, das kostet eine Ader zusätzlich ist aber verkraftbar. Das Problem mit dem quad relais läßt sich dann wohl nur mit einem mechanischem Relais umgehen - da ich leider drei Relais pro Stack brauche, muss ich mal sehen, ob ich mit externen Relais und z. B. einem digital out zum Ziel komme... ... hier bin ich aber für Vorschläge offen! gruß Martin
  5. Für eine Serie abgesetzter Steuermodule möchte ich jeweils einen Tinkerforge-Stack aus einer 24 V AC-Quelle versorgen. Die Kommunikation erfolgt via RS485 und die gesteuerten Geräte benötigen (geschaltete) 24 V AC. Um die Anzahl der Leitungen klein zu halten, war bei mit die Idee, die 24 V AC als globale Versorgung zu nutzen und den Tinkerforge-Stack daraus (nach Gleichrichtung) zu versorgen. Die Fragen: (1) Wenn ich einen Brückengleichrichter verwende, werde ich möglicherweise mehr als 24 DC am Step-Down-PS haben - Wie löse ich das am geschicktesten (Platz ist natürlich auch, wie immer, nicht viel vorhanden; Netzspannung ist tabu) ohne den PS zu zerstören (AC-Leerlaufspannung (Trafo) kann > 24 V sein! (2) kann ich mit dem Industry quad brick relay auch 24 V AC schalten? Danke im Voraus! gruß Martin
  6. Hallo, gibt es für den NEMA-17 Motor ein Drehzahl/Steps/Moment-Diagramm oder eine Angabe bis zu welcher Steppingfrequenz der Motor bei Vollschritt/Teilschritt arbeiten kann? Ich möchte den Motor zusammen mit einem Schnecken/Kegelgetriebe (~1:200) einsetzen und möchte _vorher_ die max. erreichbare Winkelgeschwindigkeit der Abtriebswelle abschätzen können! Danke für Hilfe
  7. Hallo, Danke für Hilfe und Feedback! > Danke für das Finden dieser ganzen Probleme. Wenn du noch mehr findest immer nur her damit ok - bleibe am Ball ;-) Habe aktuelle ein Image erstellen können und werde das nun testen! Bei Bedarf biete ich auch an, "custom images" zur Vefügung zu stellen! Aber erst teste ich mal, ob ich die modifizierten images nutzen kann ;-) <UPDATE> das nun erstellte image funzt! </UPDATE>
  8. grundsätzlich sollte das gehen: einen syscall aus php absetzen, darin "sudo shutdown -h now" aufrufen. in der sudoerrs einen Eintrag machen, dass der webserver-Benutzer (www-data) das Kommando "shutdown -h now" aufrufen darf (weil das darf sonst nur root). Hinweise: ich habe das mit Absicht nur "in etwa" beschrieben, da das mit erheblichen Sicherheitsbedenken behaftet ist (wenn man den RED einfach als Server betrachtet): Ein Webserver-Nutzer kann unautorisiert den Server herunterfahren ... Will man das wirklich machen, dann sollte der RED nicht aus dem Internet erreichbar sein und sicher gestellt werden, dass der Nutzer sich autorisieren muss, bevor er das Skript zum Shutdown ausführen kann, z. B. per SSL-Client-Auth.
  9. Architektur ist i386 root@tinkerforge:/usr/src/tf/red-brick/image# dpkg --print-foreign-architectures i386 unabhängig davon haben wir die Pakete manuel (node.js, c++ stdc) nachinstalliert und prepare-host und upate-sources sind durchgelaufen. Dann haben wir noch zlib1g(-dev) nachinstalliert, da es sonst zu Fehlern ("... file not found ...") für libz.so.1 beim compilieren kommt. Aktuell läuft der build process (bash ./compile-source fast)... schauen wir mal ;-)
  10. Das Skript findet Pakete (u. a. libc6 RT und NPM (java node.js?)) nicht! Meine Umgebung: wheezy (debian 7.8, stable) Fehler siehe Ende Code ... Linux tinkerforge 3.2.0-4-amd64 #1 SMP Debian 3.2.63-2+deb7u2 x86_64 The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Last login: Mon Jan 12 23:20:29 2015 from 192.168.84.210 mabri@tinkerforge:~$ mabri@tinkerforge:~$ mabri@tinkerforge:~$ sudo su root@tinkerforge:/home/mabri# cat /etc/debian_version 7.8 root@tinkerforge:/home/mabri# cat /etc/apt/sources.list # # deb cdrom:[Debian GNU/Linux 7.7.0 _Wheezy_ - Official amd64 NETINST Binary-1 20141018-13:04]/ wheezy main #deb cdrom:[Debian GNU/Linux 7.7.0 _Wheezy_ - Official amd64 NETINST Binary-1 20141018-13:04]/ wheezy main deb http://ftp.de.debian.org/debian/ wheezy main non-free contrib deb-src http://ftp.de.debian.org/debian/ wheezy main non-free contrib deb http://security.debian.org/ wheezy/updates main contrib non-free deb-src http://security.debian.org/ wheezy/updates main contrib non-free # wheezy-updates, previously known as 'volatile' deb http://ftp.de.debian.org/debian/ wheezy-updates main contrib non-free deb-src http://ftp.de.debian.org/debian/ wheezy-updates main contrib non-free # wheezy backports deb http://http.debian.net/debian wheezy-backports main contrib non-free root@tinkerforge:/home/mabri# cd /usr/src/tf/red-brick/image/ root@tinkerforge:/usr/src/tf/red-brick/image# ./prepare-host.sh + . ./utilities.sh ++ pwd + BASE_DIR=/usr/src/tf/red-brick/image + CONFIG_DIR=/usr/src/tf/red-brick/image/config + . /usr/src/tf/red-brick/image/config/common.conf ++ PATCHES_DIR=/usr/src/tf/red-brick/image/patches ++ TOOLS_DIR=/usr/src/tf/red-brick/image/tools ++ SOURCE_DIR=/usr/src/tf/red-brick/image/source ++ BUILD_DIR=/usr/src/tf/red-brick/image/build ++ APTCACHER_DIR=/usr/src/tf/red-brick/image/build/apt-cacher ++ ROOTFS_DIR=/usr/src/tf/red-brick/image/build/root-fs ++ MOUNT_DIR=/usr/src/tf/red-brick/image/build/mnt ++ OUTPUT_DIR=/usr/src/tf/red-brick/image/build/output ++ REQUIRED_HOST_PACKAGES='binfmt-support build-essential gcc-multilib git-core libstdc++6:i386 libusb-1.0-0 libusb-1.0-0-dev mount multistrap pkg-config pv python qemu qemu-user-static rsync sed tar u-boot-tools wget npm' ++ QEMU_BIN=/usr/bin/qemu-arm-static ++ TC_PREFIX=arm-linux-gnueabihf- ++ TC_DIR_NAME=gcc-linaro-arm-linux-gnueabihf-4.8-2013.10_linux ++ TC_FILE_NAME=gcc-linaro-arm-linux-gnueabihf-4.8-2013.10_linux.tar.bz2 ++ TC_URL=https://launchpad.net/linaro-toolchain-binaries/trunk/2013.10/+download/gcc-linaro-arm-linux-gnueabihf-4.8-2013.10_linux.tar.bz2 ++ COREUTILS_DIR_NAME=coreutils-8.21 ++ COREUTILS_FILE_NAME=coreutils-8.21.tar.xz ++ COREUTILS_URL=http://ftp.gnu.org/gnu/coreutils/coreutils-8.21.tar.xz ++ ADVCP_CMD=/usr/src/tf/red-brick/image/tools/coreutils-8.21/src/cp ++ UBOOT_GIT_URL=https://github.com/Tinkerforge/red-brick-u-boot-sunxi.git ++ UBOOT_GIT_BRANCH=red-brick ++ UBOOT_SRC_DIR=/usr/src/tf/red-brick/image/source/red-brick-u-boot-sunxi ++ KERNEL_GIT_URL=https://github.com/Tinkerforge/red-brick-linux-sunxi.git ++ KERNEL_GIT_BRANCH=red-brick ++ KERNEL_SRC_DIR=/usr/src/tf/red-brick/image/source/red-brick-linux-sunxi ++ KERNEL_HEADER_INCLUDE_DIR=/usr/src/tf/red-brick/image/source/red-brick-linux-sunxi/include ++ KERNEL_HEADER_USR_DIR=/usr/src/tf/red-brick/image/source/red-brick-linux-sunxi/usr ++ SUNXI_TOOLS_GIT_URL=https://github.com/Tinkerforge/red-brick-sunxi-tools.git ++ SUNXI_TOOLS_GIT_BRANCH=red-brick ++ SUNXI_TOOLS_SRC_DIR=/usr/src/tf/red-brick/image/source/red-brick-sunxi-tools ++ HOSTAPD_WPA_SUPPLICANT_NAME=wpa_supplicant_hostapd ++ HOSTAPD_WPA_SUPPLICANT_VERSION=_v4.0.2_9000.20130911 ++ HOSTAPD_WPA_SUPPLICANT_EXTENSION=.tar.bz2 ++ . /usr/src/tf/red-brick/image/config/user.conf +++ TZDATA_AREA=Europe +++ TZDATA_ZONE=Berlin +++ LOCALE=en_US.UTF-8 +++ LANGUAGE=en_US +++ LOCALE_CHARSET='en_US.UTF-8 UTF-8' +++ KB_MODEL=pc105 +++ KB_LAYOUT=de +++ KB_VARIANT= +++ KB_OPTIONS= +++ KB_BACKSPACE=guess ++ . /usr/src/tf/red-brick/image/config/developer.conf +++ CLEAN_BEFORE_COMPILE=yes + report_info 'Update package index files' + echo -e '\nInfo: Update package index files\n' Info: Update package index files + sudo apt-get update Get:1 http://http.debian.net wheezy-backports Release.gpg [836 B] Hit http://security.debian.org wheezy/updates Release.gpg Hit http://security.debian.org wheezy/updates Release Hit http://security.debian.org wheezy/updates/main Sources Hit http://security.debian.org wheezy/updates/contrib Sources Hit http://security.debian.org wheezy/updates/non-free Sources Get:2 http://http.debian.net wheezy-backports Release [147 kB] Hit http://security.debian.org wheezy/updates/main amd64 Packages Hit http://security.debian.org wheezy/updates/contrib amd64 Packages Hit http://security.debian.org wheezy/updates/non-free amd64 Packages Hit http://security.debian.org wheezy/updates/contrib Translation-en Hit http://security.debian.org wheezy/updates/main Translation-en Hit http://security.debian.org wheezy/updates/non-free Translation-en Hit http://http.debian.net wheezy-backports/main amd64 Packages/DiffIndex Hit http://http.debian.net wheezy-backports/non-free amd64 Packages/DiffIndex Hit http://http.debian.net wheezy-backports/contrib amd64 Packages/DiffIndex Hit http://http.debian.net wheezy-backports/contrib Translation-en/DiffIndex Hit http://http.debian.net wheezy-backports/main Translation-en/DiffIndex Hit http://http.debian.net wheezy-backports/non-free Translation-en/DiffIndex Hit http://ftp.de.debian.org wheezy Release.gpg Get:3 http://ftp.de.debian.org wheezy-updates Release.gpg [836 B] Hit http://ftp.de.debian.org wheezy Release Get:4 http://ftp.de.debian.org wheezy-updates Release [124 kB] Hit http://ftp.de.debian.org wheezy/main Sources Hit http://ftp.de.debian.org wheezy/non-free Sources Hit http://ftp.de.debian.org wheezy/contrib Sources Hit http://ftp.de.debian.org wheezy/main amd64 Packages Hit http://ftp.de.debian.org wheezy/non-free amd64 Packages Hit http://ftp.de.debian.org wheezy/contrib amd64 Packages Hit http://ftp.de.debian.org wheezy/contrib Translation-en Hit http://ftp.de.debian.org wheezy/main Translation-en Hit http://ftp.de.debian.org wheezy/non-free Translation-en Get:5 http://ftp.de.debian.org wheezy-updates/main Sources [1,805 B] Get:6 http://ftp.de.debian.org wheezy-updates/contrib Sources [14 B] Get:7 http://ftp.de.debian.org wheezy-updates/non-free Sources [14 B] Hit http://ftp.de.debian.org wheezy-updates/main amd64 Packages/DiffIndex Get:8 http://ftp.de.debian.org wheezy-updates/contrib amd64 Packages [14 B] Get:9 http://ftp.de.debian.org wheezy-updates/non-free amd64 Packages [14 B] Get:10 http://ftp.de.debian.org wheezy-updates/contrib Translation-en [14 B] Hit http://ftp.de.debian.org wheezy-updates/main Translation-en/DiffIndex Get:11 http://ftp.de.debian.org wheezy-updates/non-free Translation-en [14 B] Fetched 274 kB in 2s (104 kB/s) Reading package lists... Done + report_info 'Installing tools (requires root access)' + echo -e '\nInfo: Installing tools (requires root access)\n' Info: Installing tools (requires root access) + sudo apt-get install -y binfmt-support build-essential gcc-multilib git-core libstdc++6:i386 libusb-1.0-0 libusb-1.0-0-dev mount multistrap pkg-config pv python qemu qemu-user-static rsync sed tar u-boot-tools wget npm Reading package lists... Done Building dependency tree Reading state information... Done E: Unable to locate package libstdc++6 E: Couldn't find any package by regex 'libstdc++6' E: Unable to locate package npm root@tinkerforge:/usr/src/tf/red-brick/image#
  11. Ich wollte mir ein eigenes Images erstellen, komme aber leider nicht über das ./prepare_host hinweg. Ursache scheinen fehlende Repositories in der /etc/apt/sources.list des debian build hosts zu sein. Wäre es möglich eine Liste der Einträge, die für das Bauen notwendig sind zu veröffentlichen, oder habe ich die übersehen? Und: Habe ich die falsche (veraltete?) Debian Version: wheezy (stable) Muss ich auf jessie oder sid upgraden? Danke im Voraus
  12. Hi, habe versucht unter Debian das build environment zu nutzen. Leider scheitert schon mein "prepare host" mit unerfüllbaren Abhängigkeiten: + sudo apt-get install -y binfmt-support build-essential gcc-multilib git-core libstdc++6:i386 libusb-1.0-0 libusb-1.0-0-dev mount multistrap pkg-config pv python qemu qemu-user-static rsync sed tar u-boot-tools wget npm Reading package lists... Done Building dependency tree Reading state information... Done E: Unable to locate package libstdc++6 E: Couldn't find any package by regex 'libstdc++6' E: Unable to locate package npm root@tinkerforge:/usr/src/tf/red-brick/image# Was muss alles in /etc/apt/sources.list stehen, damit alle notwendigen Pakete gefunden werden? Danke für Hilfe Martin <update> ich habe dafür mal einen neuen Thread aufgemacht: http://www.tinkerunity.org/forum/index.php/topic,2826.msg17947.html#msg17947 </update>
  13. Bezogen auf die aktuelle Nutzung würde ich nicht zu stark unterteilen. Auch, weil es sicher oft übergreifende Punkte geben wird. Wichtiger finde ich ein eindeutiges und deskriptives Subject!
  14. Hi, not realy hard stuff: for the first time you can use the shell bindungs and use the execute-clause in snmpd.conf to call the bash script from snmpd. It's also possible to make this as persistent script, that communicate with snmpd each time you poll an OID. Optionaly you can write this external script in any possible language and call it in a persitant way from snmpd - have a look at the man page 5 - snmpd.conf Ok - if this is not fast enouth or to easy you can build your own snmp subagent - but be warned: documentation is somewhat short and ugly and very good C/C++-Skills and snmp-understandig is needed. From that subagent you can do all that's needed to gather information from underlaying sensors also from tf or whateverelse or can translate callbacks in traps. btw: i like snmp too! regards mabri
  15. Klar, ich habe befürchtet dass das viel Arbeit ist ;-) Erst mal auch mny tnx für den guten Job! gruß Martin
×
×
  • Neu erstellen...