Jump to content

mabri

Members
  • Gesamte Inhalte

    34
  • Benutzer seit

  • Letzter Besuch

Posts erstellt von mabri

  1. 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

  2. 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

     

     

  3. 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

  4. 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

     

     

     

  5. 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

  6. 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>

  7. 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.

  8. 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 ;-)

     

     

  9. 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#

  10. 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

  11. 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>

     

  12. 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

  13. Nur so eine Idee:

     

    Das Image basiert auf Debian...

    Debian hat einen der besten paket-manager (apt-get / aptitude / dpkg) ...

     

    Wäre es nicht möglich, Updates als .deb's zur Verfügung zu stellen?

    Das System unterscheidet zudem zwischen einfachen paket-Updates ("upgrade") und einem kompletten OS-update ("dist-upgrade")

     

     

     

    gruß

    martin

  14. Ideen:

     

    * GSM-Shield für raspi: sparqEE CELL - externe Antenne wird mitgeliefert!

    http://www.sparqee.com/portfolio/sparqee-cell/

     

    * oder einfacher externe Antenne an UMTS-Stick anschließen ..

     

     

     

    Bei dem ganzen Thema: raspi power supply - USB Hubs - UMTS -Sticks: Aus EMV-Sicht is das alles kein so besonders einfaches Thema, vor allem wenn Hochfrequenz im Wellenlängenbereich der verwendeten Kabel gepaart mit relativ hoher Sendeleistung (~ 2 Watt) zusammen kommen.

     

    Neben der (fehlenden) RFI (radio frequency imunity) der beteiligten Baugruppen kommt aber ev. hier auch noch ein einfaches Stromproblem hinzu, dass den Aufbau instabil macht.

     

    gruß

    Martin

  15. Hallo,

     

    Lösung bei mir (erst mal FastImage 1.1), da FullImage broken:

    Verwendung von /etc/init.d/network und als Config Basis /etc/network/interfaces:

    dazu: Debian Paket ifupdown installieren:

     

    apt-get install ifupdown

     

    und /etc/network/interfaces korrekt einstellen:

     

    root@red-brick:/home/tf# cat /etc/network/interfaces 
    # /etc/network/interfaces
    
    # interfaces(5) file used by ifup( and ifdown(
    auto lo
    iface lo inet loopback
    
    auto tf0
    iface tf0 inet dhcp
    

     

    das geht auch für wlan - muss ich nur wieder heraussuchen.

    wicd habe ich dann deinstalliert. Für einen headless server ok, denke ich.

    Aber ACHTUNG: Config über brickv ist dann für das Netzwerk nur noch über die brickv Console möglich!

     

    Damit ist dann auch der workaround für loopback über die rc.local überflüssig: Da /etc/network/interfaces ausgelesen wird, können da auch alle Interfaces für wlan / lan / loopback eingetragen werden.

    Weiter ist dann auch die Config von VLANs und IP-Aliases etc. alles kein Problem ... eben wie bei einem richtigen (Debian-)Server.

     

    btw: RED läuft stabil via POE über Ethernet-Master-Extension mit einem Master und vier Bricks (seit etwa 24h).

     

    NTP hält die Zeit und die Bricks antworten brav.

     

    gruß

    Martin

×
×
  • Neu erstellen...