Gå til innhold
  • Bli medlem
Støtt hjemmeautomasjon.no!

toonwolf

Medlemmer
  • Innlegg

    738
  • Ble med

  • Besøkte siden sist

  • Dager vunnet

    19

Innlegg skrevet av toonwolf

  1.  

    1 time siden, olekenneth skrev:

    sjekk om det var meg som akkurat kom hjem, hvis det er det skifter fargen på pære til grønn.

    Da gir det mening med grønn farge ja, litt sånn huset ønsker deg "velkommen hjem Ole Kenneth" ?

     

    1 time siden, olekenneth skrev:

    pæra er utrolig dårlig til å gjengi akkurat fargen grønn.

    litt nysgjerrig, hva slags pære bruker du? Selv har jeg erfaring med LED Strips inne og det blir veldig fint grønt og rødt. Har dessverre ikke bilde av grønt lys, men her er led stipe som er montert over himling i taket og som viser rødt
    ledstripe.png

    For min del blir det enten LED strips eller "trapp/terrassebelysning" utendørs som samtidig kan brukes som belysning (hvit) og hvor fargen på lyset endres når bevegelse detekteres i nærheten av døra.

     

    Tenkte å sette opp følgende regler:

    1. Om natta/når det er mørkt og ingen bevegelse detektert=hvitt lys som lyser opp på vanlig måte
    2. Hele døgnet bevegelse detektert og dør åpen=grønt lys for å vise at døra er ulåst
    3. Hele døgnet bevegelse detektert og dør låst=rødt lys for å vise at døra er låst
    1 time siden, olekenneth skrev:

    antall systemer jeg kjører, skulle du bare visst.

    men hvorfor? Kunne du klart deg med færre systemer eller har du så spesielle behov/utstyr at du må ha alle systemene for å kunne styre de? Eller liker du generelt å "fikle" med mange systemer ?

  2. Våren kommer snart og jeg ser etter en tilsvarende løsning for utebruk. Døra som låsen skal monteres på og som jeg ønsker "statuslys" for om den er låst eller ikke er plassert slik at lysene må være godt synlige. Tenker at LED striper ikke er det optimale, men kanskje LED-lanterner som både er vanntette og sannsynligvis gir et godt og skarpt lys selv i dagslys. Disse på Biltema drives av 12V og er IP67, men hvordan styre de via Z-wave?

  3. Jeg ønsket å gjenbruke et Logitech C910 webkamera som jeg hadde liggende i en skuff på en Raspberry PI3  B+ som også brukes til andre “oppgaver”. Utfordringen var å finne en løsning som ikke brukte all prosessorkraften til PI’en for å dekode video fra webkamera. C910 komprimerer hvert JPG-bilde (ramme) før det overføres til datamaskinen over USB-koblingen. Ikke alle webkameraer støtter MJPG-formatet. I så fall må Raspberry Pi utføre kompresjon av bildene før de streames over HTTP og dette fører til at CPU går i taket og du vil før eller senere få problemer. Først testet jeg Motion som er lett å sette opp og kan også trigge ved bevegelse, men siden jeg bruker Blue Iris ønsket jeg kun å ha en stream fra webkamera som er koblet til RPI’en. Deretter testet jeg ffmpeg, men det virket for komplisert til mitt bruk. Både Motion of FFmpeg tok dessuten for mye prosessorkraft fra RPI’en til at det var brukbart. Etter mye Googling kom jeg over en “fork” av MJPG-Streamer og hvor installasjon har blitt godt dokumentert av Michel Deslierres. Fordelen med MJPG-Streamer er at den bruker veldig lite CPU!

     

    Instruksjonen som jeg har laget er hentet fra dokumentasjon til Michel, er veldig forenklet og tar kun for seg hvordan du installerer MJPG-Streamer på en RPI, lager oppstartscript og setter LED på Logitech C910 til å være av ved å bruke uvcdynctrl. Om du har planer om å gjøre kamera tilgjengelig offentlig må/bør du som et minimum sikre det med brukernavn og passord. For å sette opp dette må du se i guiden til Michel Deslierres

     

    Edit: installasjonen er gjort på Raspbian Stretch med desktop (kernel versjon 4.14.98-v7+)

     

    Først sjekk om ditt webkamera støtter MJPG

    ~ $ v4l2-ctl --list-formats

    Om du får dette resultatet er du “good to go”

    Type        : Video Capture
    Pixel Format: 'MJPG' (compressed)
    Name        : Motion-JPEG
    
    

    Installer MJPEG-Streamer

    ~ $ sudo apt-get install cmake libjpeg8-dev
    ~ $ wget https://github.com/jacksonliam/mjpg-streamer/archive/master.zip
    ~ $ unzip master.zip
    ~ $ cd mjp*g-*
    ~ $ cd mjpg-*
    ~ $ make
    ~ $ sudo make install
    ~ $ cd $home

    Start mjpeg-streamer “manuelt” for å sjekke om det fungerer:

    ~ $ /usr/local/bin/mjpg_streamer -i "/usr/local/lib/mjpg-streamer/input_uvc.so -n -f 10 -r 1280x720" \
    > -o "/usr/local/lib/mjpg-streamer/output_http.so -p 8085 -w /usr/local/share/mjpg-streamer/www"
    MJPG Streamer Version.: 2.0
     i: Using V4L2 device.: /dev/video0
     i: Desired Resolution: 1280 x 720
     i: Frames Per Second.: 10
     i: Format............: JPEG
     i: TV-Norm...........: DEFAULT
     o: www-folder-path......: /usr/local/share/mjpg-streamer/www/
     o: HTTP TCP port........: 8085
     o: HTTP Listen Address..: (null)
     o: username:password....: disabled
     o: commands.............: enabled
    

    Sjekk om du får opp streamen ved å starte VLC og legge inn http://ipadressetilrpi’en:8085/?action=stream i “Open Network stream”

     

    Lag oppstartscript og starte mjpeg-streamer ved reboot

    ~ $ mkdir -p .local/bin
    ~ $ nano.local/bin/webcam-streamer

    Legg inn følgende i fila:

    #!/bin/bash
    
    # adjust these 
    
    INPUT_PLUGIN="/usr/local/lib/mjpg-streamer/input_uvc.so";
    DEVICE="/dev/video0";
    FRAMES="15";
    RESOLUTION="1280x720";
    
    OUTPUT_PLUGIN="/usr/local/lib/mjpg-streamer/output_http.so";
    PORT="8085";
    
    # the following are defaults and should not need to be changed
    EXEC="/usr/local/bin/mjpg_streamer"
    WEB_DIR="/usr/local/share/mjpg-streamer/www";
    
    
    # mjgp_streamer often does not start on first try. Why ?
    start_streamer(){
        for i in {1..5}    # try up to 5 times
        do
            ${EXEC} -b -i "${INPUT_PLUGIN} -n -d ${DEVICE} -f ${FRAMES} -r ${RESOLUTION}" -o "${OUTPUT_PLUGIN} -p ${PORT} -w ${WEB_DIR} ${CREDENTIALS}"  > /dev/null 2>&1
            sleep $((1+i)) # waiting progressively longer
            if pgrep mjpg_streamer > /dev/null
            then
              echo "mjpg_streamer started"
              return
            fi  
        done
        echo "could not start mjpg_streamer"
    }
    
    
    # Carry out specific functions when asked to by the system
    case "$1" in
            start)
                    if pgrep mjpg_streamer > /dev/null
                    then
                        echo "mjpg_streamer already running"
                    else
                        start_streamer
                    fi
                    ;;
            stop)
                    if pgrep mjpg_streamer > /dev/null
                    then
                        killall mjpg_streamer
                        echo "mjpg_streamer stopped"
                    else
                        echo "mjpg_streamer is not running"
                    fi
                    ;;
            restart)
                    if pgrep mjpg_streamer > /dev/null
                    then
                        killall mjpg_streamer
                        echo "mjpg_streamer stopped"
                    else
                        echo "mjpg_streamer is not running"
                    fi    
                    start_streamer
                    ;;
            status)
                    pid=`ps -A | grep mjpg_streamer | grep -v "grep" | grep -v mjpg_streamer. | awk '{print $1}' | head -n 1`
                    if [ -n "$pid" ];
                    then
                            echo "mjpg_streamer is running with pid ${pid}"
                            echo "mjpg_streamer was started with the following command line"
                            cat /proc/${pid}/cmdline ; echo ""
                    else
                            echo "mjpg_streamer is not running"
                    fi
                    ;;
            *)
                    echo "Usage: $0 {start|stop|restart|status}"
                    exit 1
                    ;;
    esac
    exit 0

    Skriptet må gjøres kjørbart, og katalogen der den er plassert vil bli lagt til i “system path environment variable” ved å redigere den skjulte filen .profile i hjemmekatalogen

    ~ $ chmod +x .local/bin/webcam-streamer
    ~ $ mkdir -p .local/bin
    ~ $ nano .profile
    
    # set PATH so it includes user's private .local/bin if it exists
    if [ -d "$HOME/.local/bin" ] ; then
        PATH="$HOME/.local/bin:$PATH"
    fi

    Legg inn webcam-streamer scriptet i oppstart i crontab

    ~ $ crontab -e

    Legg inn følgende helt i slutten av fila

    # Start the webcam on reboot
    @reboot /home/pi/.local/bin/webcam-streamer start && sleep 5 && /home/pi/.local/bin/webcam-streamer restart

    EKSTRA: Skru av LED på Logitech C910 webkamera

     

    Om du ønsker kan du også skru av det blå LED lyset på webkameraet. Denne instruksjonen er spesifikk for Logitech webkamera C910, men bør/skal også fungere på andre typer. Google for å se om du finne støtte for ditt webkamera.

    ~ $ sudo apt-get install uvcdynctrl
    ~ $ nano .local/bin/webcam-settings
    

    Kopier og lim inn dette:

    #!/bin/bash
    /usr/bin/uvcdynctrl -c --addctrl=046d:0990
    /usr/bin/uvcdynctrl --set='LED1 Mode' 0 # Turn off camera LED

    Sett fila til å være kjørbar

    ~ $ chmod +x .local/bin/webcam-settings

    Rediger crontab

    ~ $ crontab -e

    Legg inn følgende etter linja med webcam-streamer slik at den starter 30 sekunder etter oppstart.

     
    # Apply webcam settings
    @reboot sleep 30 && /home/pi/.local/bin/webcam-settings

    Du skal kunne se at det blå LED-lyset blir skrudd av 30 sekunder etter reboot.

    • Like 2
    • Thanks 1
  4. 23 timer siden, toonwolf skrev:

    Etter å ha satt de inn og låst opp noen ganger med kode viser den nå 85%. Enten er det batteriene fra Clas'ern som er "dårlige", eller så kan man ikke stole på batterinivået som ID Lock 150 rapporterer. Hva tror dere? Melder dette inn til ID Lock så får vi høre hva de sier om dette.

    Svar fra ID Lock i dag på hvorfor man ikke kan forvente nærmere 100% batteristatus når man setter inn nye batterier:

    Sitat

    Batteriprosenten baseres på måling av voltstyrke i batteriene ved en opplåsing. Dersom batteriene har lagt på lager en stund, kan dette ha innvirkning på batterienes kvalitet. I versjon 1.1.0 viste grafen 100% for lenge, i versjon 1.1.3 er grafen korrigert for å gi et mer riktig nivå. Nye batterier med 85% kan være helt normalt.

     

  5. 1 minutt siden, yrune skrev:

    Jeg vil tippe det er firmware problem, med mindre batteriene har ligget lenge i hylla

    Batteriene ble kjøpt inn for under en uke siden. Sjansen for at dette er et firmware problem er ganske stor gitt at dette er noe de har slitt med helt siden Z-wave modulen kom i fjor sommer. Dette er jo også noe de sier har blitt fikset i firmware 1.1.3 "Fixed a bug on battery percentage graph".

  6. Akkurat nå, yrune skrev:

    Jeg har aldri sett mer enn 70 tror jeg med nye batterier, bortsett fra når den rapporterte 100 hele tiden i starten. Nå har ikke jeg lagt inn den firmware enda

    Uansett forventer jeg mer enn 85% når det monteres nye batterier. Kanskje ikke 100%, men et sted mellom 95-100% kanskje?

  7. På 10.3.2019 den 20.53, toonwolf skrev:

    3 stk. ID Lock 150 oppdatert til firmware 1.1.3. Alle har etter oppdateringen fått 65% batterinivåstatus! Dette kan ikke være en tilfeldighet. Noen flere som har oppdatert og hvilken prosent har dere etter oppdateringen? Husk at du må manuelt låse opp med kode eller brikke for at batteristatus skal bli oppdatert.

    Jeg klarer ikke å slå meg til ro med at 3 stk. ID Lock 150 viser samme batterinivå (65%) etter oppdatering av firmware. Vel så ble de byttet i høst på omtrent samme tid, men bruk av låsene er veldig forskjellig og jeg hadde forventet at det i det minste skulle være avvik på noen prosenter. Kjøpte meg derfor nye Clas'ern AA batterier og satte de inn i en av låsene (som viser 65%). Etter å ha satt de inn og låst opp noen ganger med kode viser den nå 85%. Enten er det batteriene fra Clas'ern som er "dårlige", eller så kan man ikke stole på batterinivået som ID Lock 150 rapporterer. Hva tror dere? Melder dette inn til ID Lock så får vi høre hva de sier om dette.

  8. På 10.3.2019 den 20.53, toonwolf skrev:

    oppdatert til firmware 1.1.3. Alle har etter oppdateringen fått 65% batterinivåstatus

    Er det virkelig ingen andre som har oppdatert firmware til 1.1.3? Eller er det slik at dere ikke har 65% batterinivåstatus?

  9. På 11.3.2019 den 10.56, Mastiff skrev:

    Men så snart jeg hadde slått på GPS-en, var oppdateringen i gang.

    Så du har ikke fått med deg at ID Lock nå har startet med å spore hvor kundene befinner seg til enhver tid? Det er noe nytt de har begynt med og en forutsetning for at du skal kunne bruke låsene deres ? Spøk til side, bra det løste seg for deg!

  10. 3 stk. ID Lock 150 oppdatert til firmware 1.1.3. Alle har etter oppdateringen fått 65% batterinivåstatus! Dette kan ikke være en tilfeldighet. Noen flere som har oppdatert og hvilken prosent har dere etter oppdateringen? Husk at du må manuelt låse opp med kode eller brikke for at batteristatus skal bli oppdatert.

  11. 2 timer siden, Mastiff skrev:

    Jeg får kontakte supporten på ID Lock

    Lykke til, hold oss andre oppdatert på hva som skjer med denne saken.

  12. 10 minutter siden, Mastiff skrev:

    Denne låsen er oppdatert to ganger før

    Sorry @Mastiff da har jeg ikke noen tips annet at du må ta kontakt med support hos ID Lock. Med nye batterier, to forskjellige mobiler, nullstilling av låsen før oppdatering så tror jeg selv support hos de skal slite med å finne på noe du kan prøve. Bare ikke bli voldelig, det pleier sjelden å hjelpe ?

  13. 1 time siden, Mastiff skrev:

    uten at det heller lyktes.

    Jeg husker at første gang jeg skulle oppdatere firmware på alle 3 låsene slet jeg også med å få kontakt med de. Jeg har også Android og måtte "drepe" oppdateringsappen i minnet på mobilen for at jeg til slutt klarte å få kontakt. Tror problemet her ligger i appen og ikke selve låsen. Etter første versjon med oppdatering har de følgende versjonene blitt oppdatert uten noen som helst problemer

  14. 21 minutter siden, Mastiff skrev:

    Er det noen flere forslag, før jeg kontakter ID Lock?

    Har du tatt omstart av låsen (fjernet batteriene) etter oppdatering av firmware?

  15. 2 timer siden, toonwolf skrev:

    feil med visning av batterinivå

    Etter oppdatering ramlet batteriprosenten fra 90 til 65% på en lås. Dette stemmer nok mer med hva som er riktig siden dette er batterier som ble satt inn i høst.

    • Like 1
  16. Fikk tips om å koble slik:

     

    UMV3 Svart til UMV3 Orange
    UMV3 Brun til EL580 Grønn
    UMV3 Rød til EL580 Rød

    Det var ikke tegn til at EL580 låsen fikk strøm i det hele tatt. Kanskje det ikke er "støtte" for "omvendt funksjon" i Danalock UMV3? Har tatt kontakt med Danalock via @INTIN RuneV , men venter fortsatt på svar fra Danalock. EL580 låsen er nok ikke det mest vanligste som blir koblet opp med denne sikkert?

  17. Noen som kan hjelpe meg med å finne riktig måte å koble en Danalock UMV3 mot en EL580 fallelås (solenoid) som er satt i "omvendt" funksjon? Dvs at låsen er ulåst så lenge den ikke får strøm. Jeg har fått til noe som ligner, men da fungerer det slik at låsen låses når jeg låser opp med Danalock appen. Altså funsksjonaliteten er der, bare at den må være omvendt. Slik har jeg koblet:

     

    DC 12v 1amp til UMV3

    + til UMV3 Grå (Power Input)

    - til UMV3 Hvit (Ground)

     

    UMV3 til EL580

    Brun (Power output) til Rød 1 (+)

    Svart (Ground) til Grønn 1 (-)  

    Blå1 (Common) til Svart 2 (C-Felles)

    Lilla1 (Normally closed) til Gul 3 (NC-Låst)

     

    Her er koblingsdiagram for UMV3 hentet fra UMV3 User Guide

    wiring_diagramumv3.png.6e968d32505040f25ceba17a32304e6d.png

     

    Her er koblingsdiagram for EL580 låsen som har blitt satt i "omvendt funksjon" som gjør at låsen vil være åpen så lenge den ikke får strøm.

    el580diagram.thumb.png.04fbd8a34a41adaad0575c82f25b2065.png

  18. På 28.2.2019 den 12.19, cscheiene skrev:

    Punkt 2,  dette fungerer fint for systemer som har implementert dette. Kjenner ikke til HomeSeer, men de burde ikke trenge mer en zwave manualen til ID Lock for å få til dette. Dette er ikke noe unikt for ID Lock, følger zwave spec som andre låser på dette punktet

    HomeSeer support har nå svart at de trenger låsen fysisk for å få til dette og at det ikke holder med informasjonen som jeg har sendt med henvisning til Z-Wave manualen til ID Lock 150 for å legge til "Door Condition". Synes det er merkelig, men nå kan jeg ikke utrope meg til å være noen HomeSeer ekspert heller. Hva mener dere andre om dette?

×
×
  • Opprett ny...

Viktig informasjon

Vi har plassert informasjonskapsler/cookies på din enhet for å gjøre denne siden bedre. Du kan justere dine innstillinger for informasjonskapsler, ellers vil vi anta at dette er ok for deg.