Till er som är duktiga på att programmera HC2!
Jag har en HC2 och ett Verisure larm. Jag har tittat på smartplug varianten för att hämta larmstatus men det verkar lite omständigt då båda enheterna är uppkopplade. Borde man inte kunna hämta status med hjälp av: https://github.com/suhajdab/verisure-api
Då kan man sätta globala variabler som kan köra scener för Larm PÅ/AV, Skalskydd PÅ/AV och LARM?
Vore smidigt att skapa en plugin för Verisure när man kan lägga till såna igen..
Bara en idé, tror ni att det är möjligt att göra något med detta?
Ha det gott!
Verisure API - Hämta status?
Du kan, precis som du själv föreslår, ha en lokal burk, typ Raspberry Pi, som använder Verisure API:t för att hämta status från larmet och spegla över det till HC2:an mha av Fibaros REST API.
Har gjort ett motsvarande program som speglar över status från Siemens SPC till HC2, som du kan hämta inspiration från. Du hittar mitt program på https://github.com/Goran58/node-spc-fibaro-hc2-binding
//Göran
Har gjort ett motsvarande program som speglar över status från Siemens SPC till HC2, som du kan hämta inspiration från. Du hittar mitt program på https://github.com/Goran58/node-spc-fibaro-hc2-binding
//Göran
Vanderbilt SPC integration, Z-Wave, Zigbee, MySensors, LoRaWAN, Linux, Raspberry PI, OpenWRT
Hej!
Jag var först också inne på att försöka konvertera dessa skript men efter lite funderande valde jag att avstå och istället köra varianten med pluggar.
Främsta skälet var att det blir för många inblandade parter, förutom FHC och Verisure box behöver du även en separat dator/NAS och access till Verisures website. Kör du med pluggarna så har du en lösning som bara involverar 2 parter (FCH och Verisure box).
Men...via skriptet kan du få fram mer info, borde även gå att bygga så du kommer åt historiken, vem som larmat/larmat av etc så jag funderar på att ev komplettera min nuvarande lösning med pluggar.
Jag var först också inne på att försöka konvertera dessa skript men efter lite funderande valde jag att avstå och istället köra varianten med pluggar.
Främsta skälet var att det blir för många inblandade parter, förutom FHC och Verisure box behöver du även en separat dator/NAS och access till Verisures website. Kör du med pluggarna så har du en lösning som bara involverar 2 parter (FCH och Verisure box).
Men...via skriptet kan du få fram mer info, borde även gå att bygga så du kommer åt historiken, vem som larmat/larmat av etc så jag funderar på att ev komplettera min nuvarande lösning med pluggar.
HC2 ver 4.160 med prylar från Aeon Labs, Fibaro, Philio, TKBHome, D-link, Sonos, Yamaha, LG, Yale och Verisure. Nu styrs även rullgardinerna från HC .
-
- Medlem
- Posts: 102
- Joined: 30 Nov 2013, 11:08
- 10
- Location: Skegrie
Githubsidan är borta. Haer verisure stoppat alla möjligheter för att få status från enheterna eller sur ser det ut nu, ett år senare?
Ja vem vet, han har säkert fått ett förmaningsbrev även om det verkar konstigt. Är ju inte något fuffens man gör. Jag fick bygga om lite i hans kod då den var gjord för att köras i en scheduler för OpenHAB. Kör den som en tjänst på en RPi där den pollar var 30e sek och uppdaterar några globala variabel via HC2ans API om något ändras. Mitt hus släcker sig självt och stänger av strömmen till garagemotorn när jag larmar.. Stable i 4mån sen jag lämnade det.
Byggde en enkel VD för att visa Status, tid, namn och olika ikoner för status på HC2an. Finns ingen notis för pågående larm dock, det vill inte Verisure att man ska få veta som kund.
Jag måste kolla upp varför Github projektet är borta innan jag postar något. Vill man köra detta ska man ha lite hum om linux+node.js men labbar man lite så löser man det.
Jag skulle säga att detta är en mycket smuttare lösning än att köpa flera Verisurepluggar+brytare/Universalsensor och sen sätta ihop detta. Det tar plats, du kastar funktionalitet från pluggarna i sjön, dyrt, fler saker som kan pajja(inte färre). Det enda som är bra är att du får larmstatus vid pågående larm. Då kan man få huset att blinka/byta färg och annat kul.
Det enda som behövs är en RPi eller liknande..
Byggde en enkel VD för att visa Status, tid, namn och olika ikoner för status på HC2an. Finns ingen notis för pågående larm dock, det vill inte Verisure att man ska få veta som kund.
Jag måste kolla upp varför Github projektet är borta innan jag postar något. Vill man köra detta ska man ha lite hum om linux+node.js men labbar man lite så löser man det.
Jag skulle säga att detta är en mycket smuttare lösning än att köpa flera Verisurepluggar+brytare/Universalsensor och sen sätta ihop detta. Det tar plats, du kastar funktionalitet från pluggarna i sjön, dyrt, fler saker som kan pajja(inte färre). Det enda som är bra är att du får larmstatus vid pågående larm. Då kan man få huset att blinka/byta färg och annat kul.
Det enda som behövs är en RPi eller liknande..
-
- Medlem
- Posts: 102
- Joined: 30 Nov 2013, 11:08
- 10
- Location: Skegrie
Han har säkert fått ett CAD. Jag håller helt med om att det är betydligt bättre att inte hacka med pluggar även om det inte heller är så svårt. Har flera RPis som ligger och väntar på projekt och jag har inte några problem med att labba även om jag inte kört just node.js så mycket tidigare. Fint att höra att det fortfarande fungerar samtidigt som det är kanon att ha pluggarna so backup om verisure skulle hitta på några dumheter i framtiden.
Öppna och dokumentera era APIn för h***ete..... bäst för alla.
Öppna och dokumentera era APIn för h***ete..... bäst för alla.
Jag har 4 st Yale Doorman och inget Verisure Larm. Dock så har jag deras app och kan öppna och stänga dörrarna med dessa.
Tyvärr så kan man inte ställa in så att pluggarna reagerar på om låset är stängt eller öppet.
Det är möjligt att det fungerar om man även har deras larm.
Är intresserad av att veta mer om hur man kan hämta status på låsen.
Kör en HC2.
Tyvärr så kan man inte ställa in så att pluggarna reagerar på om låset är stängt eller öppet.
Det är möjligt att det fungerar om man även har deras larm.
Är intresserad av att veta mer om hur man kan hämta status på låsen.
Kör en HC2.
-
- Ny medlem
- Posts: 1
- Joined: 30 Jan 2017, 12:39
- 7
Då jag inte kända mig bekväm i att ge något api inloggnings möjligheter till Verisure så är min plan att skapa en användare där som får notifikationer via epost när någon larmar av eller på.
Dvs. jag kommer att kolla status genom att läsa e-post meddelanden via antingen IMAP eller POP3, notera att jag inte har börjat än dvs. jag har ingen kod att dela med mig än.
Dvs. jag kommer att kolla status genom att läsa e-post meddelanden via antingen IMAP eller POP3, notera att jag inte har börjat än dvs. jag har ingen kod att dela med mig än.
Vad skall du använda det till? Känns som det potentiellt sett kan bli en ganska lång fördröjning mellan av/på- larmning och mottagande av notifieringen?
Samtidigt kan det ju på ett sätt vara bättre än att bygga något mot ett icke publikt API som kan förändras utan förvarning.
Lösningen med att kontrollera status via smartplugs är nog fortfarande det enklaste och pålitligaste (dock ej billigaste).
Samtidigt kan det ju på ett sätt vara bättre än att bygga något mot ett icke publikt API som kan förändras utan förvarning.
Lösningen med att kontrollera status via smartplugs är nog fortfarande det enklaste och pålitligaste (dock ej billigaste).
Har skrivit en applikation som läser eposten för att få status på låset och det fungerar ganska bra med viss fördröjning men den beror mest på att jag bara kollar eposten varje minut. Eposten levereras ganska omgående. Problemet har snarare varit att tolka eposten så att man vet vad som har hänt och att det är rätt dörr.
-
- Medlem
- Posts: 102
- Joined: 30 Nov 2013, 11:08
- 10
- Location: Skegrie
Kollade på detta nyss och en googling fick fram detta: https://github.com/persandstrom/python-verisure
Testade nyss och det fungerar prima.
Testade nyss och det fungerar prima.
Jag inser att jag saknar en del grundläggande kunskap om hur man lagrar data i RPi och hur man får över datat från RPi till HC2.
Är det tex HC2 som ropar på RPi för att hämta data eller är det RPi som skickar in till HC2 via något API? Vem är den aktiva parten så att säga?
Hur bär man sig åt för att HC2 och RPi skall veta vilka adresser den andra parten sitter på? Jag har noterat att mina byter adress ibland när jag startat om dom så då vill man man ju inte hårdkoda adresserna.
Programsnutten som snurrar i RPi-n, lagrar den undan data på något fiffigt sätt?
@ cortez och starkjohan: skulle du ha lust att dela med dig av koden du kör på din RPi och på HC2 för att få det här att funka?
En annan tanke: det verkar ju som att HC2 kör Linux så det vore ju smutt om man kunde skippa RPi-n helt och hållet och köra allt i HC2-an.
Är det tex HC2 som ropar på RPi för att hämta data eller är det RPi som skickar in till HC2 via något API? Vem är den aktiva parten så att säga?
Hur bär man sig åt för att HC2 och RPi skall veta vilka adresser den andra parten sitter på? Jag har noterat att mina byter adress ibland när jag startat om dom så då vill man man ju inte hårdkoda adresserna.
Programsnutten som snurrar i RPi-n, lagrar den undan data på något fiffigt sätt?
@ cortez och starkjohan: skulle du ha lust att dela med dig av koden du kör på din RPi och på HC2 för att få det här att funka?
En annan tanke: det verkar ju som att HC2 kör Linux så det vore ju smutt om man kunde skippa RPi-n helt och hållet och köra allt i HC2-an.
Fibaro HC2 4.600
Ett 60-tal pryttlar, de flesta från Fibaro, några från Qubino och Schneider. Några egenutvecklade baserade på Z-Uno. Integration mot Nibe API och Verisure API
Ett 60-tal pryttlar, de flesta från Fibaro, några från Qubino och Schneider. Några egenutvecklade baserade på Z-Uno. Integration mot Nibe API och Verisure API
-
- Medlem
- Posts: 102
- Joined: 30 Nov 2013, 11:08
- 10
- Location: Skegrie
Jag har inte brytt mig om att skriva något LUA-script till HC2 ännu till just Verisure-pythonscriptet, annars hade jag gärna delat med mig. Jag har bara testat pythonscriptet i en freebsd-miljö och konstaterat att det fungerar fint. Nästa steg är att skriva ett enkelt api t.ex. i PHP som kan kommunicera med pythonscriptet. Pythonscriptet kan man köra i de flesta miljöer inkl. RPi. HC2 kan sen hämta och skicka data till APIt.
IP-adresserna bör du definitivt ordna. Fast/reserverat IP på alla inblandade enheter är enklast och stabilast. Hårdkodade adresser underlättar. Dom kan också lagras i variabler på HC2 om man vill hålla det någorlunda dynamiskt.
Du kan inte köra pythonscript på din HC2 utan att "hacka" den vilket jag inte skulle ge mig på utan att veta exakt vad jag höll på med.
IP-adresserna bör du definitivt ordna. Fast/reserverat IP på alla inblandade enheter är enklast och stabilast. Hårdkodade adresser underlättar. Dom kan också lagras i variabler på HC2 om man vill hålla det någorlunda dynamiskt.
Du kan inte köra pythonscript på din HC2 utan att "hacka" den vilket jag inte skulle ge mig på utan att veta exakt vad jag höll på med.
-
- Medlem
- Posts: 102
- Joined: 30 Nov 2013, 11:08
- 10
- Location: Skegrie
Det är alltså länken i mitt oktoberinlägg jag syftar på. Det pythonscriptet är väldigt mycket bättre än tidigare nämnda lösningar i tråden.
Nu har jag fixat en riktig integration mha Sandströms bibliotek precis som några tidigare här i tråden och delar här med mig av min kod och mina upptäckter så här långt.
Ett trubbel dök upp under testningen: Jag får felmeddelande tillbaka från Verisure efter ett antal anrop till API't om jag anropar för ofta:
Verisure har använt felkod 401 ett tag med nu har dom gått över till felkod 429.
Felrapport: "Invalid response, status code: 401 - Data: {"errorGroup":"UNAUTHORIZED","errorCode":"AUT_00021","errorMessage":"Request limit has been reached"}
Felrapport: "Invalid response, status code: 429 - Data: {"errorGroup":"UNAUTHORIZED","errorCode":"AUT_00021","errorMessage":"Request limit has been reached"}
Jag har laborerat med olika pollningsfrekvenser för att utröna var gränsen går. Slutsatsen är att 120 sekunder är det kortaste intervallet man kan ha om man vill undvika upprepade felmeddelanden.
Nedan är mina testresultat.
Jag har två timers i VDn som håller koll på pollningsfrekvens:
Pollning_OK : Denna anger väntetid till nästa anrop så länge allt går bra.
Pollning_NOK : Denna anger väntetid till nästa anrop om ett fel inträffat.
Jag har satt Pollning_NOK=240 sekunder. Kortare är ju meningslöst eftersom man då kommer nära ordinarie pollningsfrekvens. Och längre är ju heller inte meningsfullt, då är det bättre att från början se till att inte ha en för hög pollningsfrekvens som orsakar fel.
Så här ser det ut för olika värden på Pollning_OK:
5 sekunder : Fel 401 efter 10 anrop (ca en minut)
30 sekunder : Fel 401 efter 15 anrop (ca 7 minuter)
55 sekunder : Fel 401 efter 18, 66, 5, 7, 15 anrop
60 sekunder : Fel 401 efter 127, 42, 52, 20, 12, 3, 3, 27, 63, 13, 16, 16, 2, 12 anrop
70 sekunder : Fel 401 efter 4, 2, 9, 18, 42, 53 anrop
90 sekunder : Fel 401 efter 290 (7,25 tim) , 22, 6, 40, 39, 61, 26, 3, 120, 25, 174 (4,5 tim)
100 sekunder: Fel 429 efter 788 (22 tim), 6, 490 (13,5 tim), 8, 3 anrop
110 sekunder: Fel 421 efter 1198 (36,5 tim), 10 anrop
120 sekunder: Inga fel. Har tuffat på i veckor nu utan problem
Om det är så att Verisure begränsar antal anrop per tidsenhet så betyder det att vissa användningsfall blir meningslösa, tex om man vill tända belysning när man kommer hem och larmar av. Om det tar flera minuter innan HC2 ens vet om att det är avlarmat så missar man ju poängen lite. För just det användningsfallet fungerar lösningen med pluggar bättre, då blir det ingen som helst fördröjning i systemet. Så har jag det riggat just nu, jag larmar av på utsidan dörr och innan jag ens hunnit öppna dörren så har ljuset tänts i huset. Precis som det ska va.
Så här ser det ut: http://www.zwaveforum.se/viewtopic.php? ... 827#p20827
Däremot är det ju fint att man kan hämta temperaturer från rummen tex och där behövs ju ingen sekundsnabb uppdatering. Återstår att lista ut hur man skall få in temperaturerna i HC2 så att den uppfattar min VD som en temperaturgivare. Samma utmaning som med min NIBE värmepump från vilken jag kan läsa temperaturer från deras API till en VD, jag vill ju att temperaturerna skall uppfattas som klimatdata av HC2-an.
Bifogar mina kodsnuttar för den som vill spara lite tid.
Min VD använder ett antal globala variabler för att lagra statusvärden och temperaturer. Jag har också definierat en "Notification" som skickas till min mobiltelefon om bryggan till Verisure av någon anledning går ner. Jag har också laddat upp en Verisure-ikon som refereras till i koden.
Knapparna "På" och "Av" sätter på respektive stänger av VDn om man skulle vilja pausa den en stund.
Variabler som används : Fördefinerade variabler som används: Mycke nöje!
Ett trubbel dök upp under testningen: Jag får felmeddelande tillbaka från Verisure efter ett antal anrop till API't om jag anropar för ofta:
Verisure har använt felkod 401 ett tag med nu har dom gått över till felkod 429.
Felrapport: "Invalid response, status code: 401 - Data: {"errorGroup":"UNAUTHORIZED","errorCode":"AUT_00021","errorMessage":"Request limit has been reached"}
Felrapport: "Invalid response, status code: 429 - Data: {"errorGroup":"UNAUTHORIZED","errorCode":"AUT_00021","errorMessage":"Request limit has been reached"}
Jag har laborerat med olika pollningsfrekvenser för att utröna var gränsen går. Slutsatsen är att 120 sekunder är det kortaste intervallet man kan ha om man vill undvika upprepade felmeddelanden.
Nedan är mina testresultat.
Jag har två timers i VDn som håller koll på pollningsfrekvens:
Pollning_OK : Denna anger väntetid till nästa anrop så länge allt går bra.
Pollning_NOK : Denna anger väntetid till nästa anrop om ett fel inträffat.
Jag har satt Pollning_NOK=240 sekunder. Kortare är ju meningslöst eftersom man då kommer nära ordinarie pollningsfrekvens. Och längre är ju heller inte meningsfullt, då är det bättre att från början se till att inte ha en för hög pollningsfrekvens som orsakar fel.
Så här ser det ut för olika värden på Pollning_OK:
5 sekunder : Fel 401 efter 10 anrop (ca en minut)
30 sekunder : Fel 401 efter 15 anrop (ca 7 minuter)
55 sekunder : Fel 401 efter 18, 66, 5, 7, 15 anrop
60 sekunder : Fel 401 efter 127, 42, 52, 20, 12, 3, 3, 27, 63, 13, 16, 16, 2, 12 anrop
70 sekunder : Fel 401 efter 4, 2, 9, 18, 42, 53 anrop
90 sekunder : Fel 401 efter 290 (7,25 tim) , 22, 6, 40, 39, 61, 26, 3, 120, 25, 174 (4,5 tim)
100 sekunder: Fel 429 efter 788 (22 tim), 6, 490 (13,5 tim), 8, 3 anrop
110 sekunder: Fel 421 efter 1198 (36,5 tim), 10 anrop
120 sekunder: Inga fel. Har tuffat på i veckor nu utan problem
Om det är så att Verisure begränsar antal anrop per tidsenhet så betyder det att vissa användningsfall blir meningslösa, tex om man vill tända belysning när man kommer hem och larmar av. Om det tar flera minuter innan HC2 ens vet om att det är avlarmat så missar man ju poängen lite. För just det användningsfallet fungerar lösningen med pluggar bättre, då blir det ingen som helst fördröjning i systemet. Så har jag det riggat just nu, jag larmar av på utsidan dörr och innan jag ens hunnit öppna dörren så har ljuset tänts i huset. Precis som det ska va.
Så här ser det ut: http://www.zwaveforum.se/viewtopic.php? ... 827#p20827
Däremot är det ju fint att man kan hämta temperaturer från rummen tex och där behövs ju ingen sekundsnabb uppdatering. Återstår att lista ut hur man skall få in temperaturerna i HC2 så att den uppfattar min VD som en temperaturgivare. Samma utmaning som med min NIBE värmepump från vilken jag kan läsa temperaturer från deras API till en VD, jag vill ju att temperaturerna skall uppfattas som klimatdata av HC2-an.
Bifogar mina kodsnuttar för den som vill spara lite tid.
Min VD använder ett antal globala variabler för att lagra statusvärden och temperaturer. Jag har också definierat en "Notification" som skickas till min mobiltelefon om bryggan till Verisure av någon anledning går ner. Jag har också laddat upp en Verisure-ikon som refereras till i koden.
Knapparna "På" och "Av" sätter på respektive stänger av VDn om man skulle vilja pausa den en stund.
Variabler som används : Fördefinerade variabler som används: Mycke nöje!
- Attachments
-
- Verisure interface on Raspberry Pi.zip
- Python-skript för Raspberry Pi
- (1.35 KiB) Downloaded 422 times
-
- Verisure ikon
- Verisure VD ikon.png (13.66 KiB) Viewed 24171 times
-
- Verisure virtual device.zip
- Verisure VD
- (3.94 KiB) Downloaded 395 times
Fibaro HC2 4.600
Ett 60-tal pryttlar, de flesta från Fibaro, några från Qubino och Schneider. Några egenutvecklade baserade på Z-Uno. Integration mot Nibe API och Verisure API
Ett 60-tal pryttlar, de flesta från Fibaro, några från Qubino och Schneider. Några egenutvecklade baserade på Z-Uno. Integration mot Nibe API och Verisure API
-
- Medlem
- Posts: 102
- Joined: 30 Nov 2013, 11:08
- 10
- Location: Skegrie
Ser prydligt ut. Fint att du delar med dig, koden kommer helt klart vara till nytta för fler än dig. Ska ta hem och titta på den "någon gång"