toonwolf

Da gir det mening med grønn farge ja, litt sånn huset ønsker deg "velkommen hjem Ole Kenneth" ? 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 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: Om natta/når det er mørkt og ingen bevegelse detektert=hvitt lys som lyser opp på vanlig måte Hele døgnet bevegelse detektert og dør åpen=grønt lys for å vise at døra er ulåst Hele døgnet bevegelse detektert og dør låst=rødt lys for å vise at døra er låst 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 ?

hvorfor akkurat grønn? Forresten imponert over antall systemer du kjører!

hmm, kanskje det beste er å kjøre på med LED Trappelys og Fibaro RGB kontroller

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?

done

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.

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

På tide å kjøpe seg et multimeter...

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

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

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.

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

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!

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.

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

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 ?

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

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

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.

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?

Firmware Version 1.1.3 (Public Beta) er ute for ID Lock 150. Dessverre ser det ikke ut til at de har fikset problemet med at du ikke får status på hvilken kode som ble brukt om du åpner døra før du får "tuddelutt". De som har slitt med høyt forbruk av batterier og feil med visning av batterinivå kan derimot glede seg?

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

Svar fra ID Lock nå: "Vi sender låsen til dem (HomeSeer) i neste uke. Du får et vink når den er avgårde." Oppdatering følger...

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?

Startet i "IT-bransjen" for 25 år siden og har jobbet med stort sett det meste utenom programmering, akkurat det har vært første bud ja!