rozon

Den funker. Bryteren funker ikke enda.


Sent from my iPhone using Tapatalk

Da var første PR på deCONZ til Domoticz lagt inn. Plukker opp lamper og lar deg styre disse i Domoticz.

https://github.com/domoticz/domoticz/pull/2772

Hvis du vil teste dette så er det fullt mulig uten å kludre til setup du allerede har. :) Lurer du på noe, så bare spør.

Skal også legge til sensorer, men det blir en senere PR da jeg må teste en del mer før jeg tør sende den inn i development. I første omgang IKEA brytere og sensorer, deretter sensorer jeg får info om. :)

Og sånn plutselig nå kommer sensorene inn uten problem. Ingenting er endret, men plutselig virker det. Er ikke stabilt dette...

Edit: Ok, 1 kom inn uten problem. Endte opp med å bruke en ny RPi 3+ og samme DB og da virker alt rimelig greit.

I følge ZigBee standarden er koordinatoren alltid NWK 0x0000, så det synes jeg ikke er så rart. 

Ok, så kjører jeg beta da... Men har ikke satt opp noe beta channel på apt sources, og det er .34 som kommer der.

Her er et screen fra deCONZ appen på RaspBee:

Sensoren er der, men ikke i web UI.

Nei, fikk ikke bedre resultat. Men, jeg kan ikke vite om naboen har pærene sine på og det er veldig upraktisk å måtte banke på alle dørene for å skrudd av alt ZigBee utstyr for å pare en sensor.

Jeg har vel kjørt deConz i 2 år og var kjempefornøyd lenge. I april ble jeg kjempehappy for å kunne bruke sensorer, men nå virker ikke det lengre, og i hele perioden fra april har det vært 1-2 lamper som må cycles hver dag. Sånn var det ikke før!

Kjører ikke beta software. Kjører release:

https://www.dresden-elektronik.de/funktechnik/solutions/wireless-light-control/raspbee-gw-sd-card-image/?L=1

7 hours ago, ZoRaC said:

Tipset du fikk fra "manup" er verdt et forsøk, for da tvinger du sensorene til å pares direkte mot RaspBee i stedet for via en lyspære (som av og til kan feile):

https://github.com/dresden-elektronik/deconz-rest-plugin/issues/733

 

Hadde også vært interessant å testet samme versjon på Windows mot ConBee-pinnen din, bare for å se om det har blitt innført en bug i den versjonen:

https://www.dresden-elektronik.de/deconz/win/deCONZ_Setup_Win32_V2_05_34.exe

Done that, men det er ikke en praktisk løsning... mer en walk around the big pink elephant. Produktet er blitt ustabilt. RaspBee var dønn i den tiden jeg kjøpte, og den vekket til liv døde Hue pærer osv. I dag er det nesten en daglig ting å gå rundt i huset å skru av og på lamper som er blitt inaktive i RaspBee over natten.

Og ja, jeg har testet med flere versjoner og det funker av og til med noen versjoner. Jeg har desverre ikke tid til å være QA for Dresden, og jeg vil ikke bruke noe som av og til virker. 

Har hatt deCONZ på en RasbeeGW kjørende i de siste årene. De siste månedene har jeg også hatt Ikea sine Motion sensorer og alt har virket perfekt. Til i går.

Oppgraderte HASS. Da klikka deConz modulen i Hass. Oppdaterte deConz. Vips der fikk jeg ikke lengre paret sensorene. Shit!

Rigga opp en annen deConz på USB som jeg hadde liggende. La inn samme FW som Rasbee og vips. Der paret de med en gang! Tilbake å prøve på Rasbee... No luck.

ARGH! Noen tips?

På soverommet har jeg bevegelsessensor og bryter. Tanken er å ha bevegelsesstyrt lys når bryteren er PÅ. I tillegg vil jeg at bryteren slår av og på lyset når den brukes, så jeg slipper vente 15 minutter på at lyset skal gå av når jeg legger meg.

Tanker eller optimaliseringer på koden?

- alias: "E2 Bedroom Skru av lyset etter 15 minutter"
  trigger:
    - platform: state
      entity_id: binary_sensor.e2_bedroom_motion
      to: 'off'
      for:
        minutes: 15
        seconds: 00
  action:
    - service: light.turn_off
      data:
        entity_id:
          - light.e2_soverom_taklampe

- alias: "E2 Bedroom Skru på lys ved bevegelse"
  trigger:
    - platform: state
      entity_id: binary_sensor.e1_bedroom_motion
      to: 'on'
  condition:
    - condition: state
      entity_id: 'switch.bedroom'
      state: 'on'
  action:
    - service: light.turn_on
      data:
        brightness: 255
        entity_id:
          - light.e2_soverom_taklampe

- alias: "E2 Bedroom Turn off lights switch"
  trigger:
    - platform: state
      entity_id: switch.bedroom
      to: 'off'
  action:
    - service: light.turn_off
      data:
        entity_id:
          - light.e2_soverom_taklampe

- alias: "E2 Bedroom Turn on lights switch"
  trigger:
    - platform: state
      entity_id: switch.bedroom
      to: 'on'
  action:
    - service: light.turn_on
      data:
        brightness: 255
        entity_id:
          - light.e2_soverom_taklampe

Takk for tips, men hadde allerede basicen.

Hårene reiser seg i nakken...

Brukte 2 timer på å mikse opp og ned på sekvensen min. Som et last ditch tok jeg å klippet den ut av "packagen" og inn i automations.yaml... Så virka dritten.

Kommer fra Domoticz der dette var plankekjøring. Ikke så stødig i HASS enda, men..

Har ca 20 bevegelsesensorer i huset som skal skru av og på lys. Hvordan gjøre det enklest mulig...?

I større prosesser tenker man gjerne på innslagskost også, og da hjelper hysterese. På en varmeovn vil man bruke effekt med en gang man skrur på, men varmen kommer først seinere. Derfor er det mer energieffektivt å la temperaturen gå over set verdien med færre innslag enn hyppige justeringer. 

Er jo hvor mye man vil gjøre ut av det liksom. 

I dag krasjet databasen min. DeviceStatus tabellen er helt tom, og huset er rimelig statisk. Det får meg til å tenke litt på fremtiden til Domoticz, som jeg ikke ser på som veldig lys med mindre det gjøres store endringer. Joda, jeg gjennoppretter fort databasen og det er ikke helt grunnen til dette innlegget. Det jeg vil frem til er en smule tyngre.

Domoticz oppstod sammen med RFXtrx transceiverne, og veldig mye av bakgrunnen og hvordan ting gjøres i Domoticz er knyttet til nettopp disse gamle (stødige) og udødelige protokollene. Vi ser jo dette i device lista vår der nye Z-Wave enheter blir lagt inn som gode gamle Oregon instrumenter. Saken er den at å legge til ny hardware i Domoticz er å translere den nye dingsen til et format som kan passe med eksisterende devices.

Sånn kan vi fortsette i mange år til, men kaster vi på en måte perler for svin med å støtte opp rundt dette istedet for å starte prosessen med å modernisere systemet? Jo mer hardware vi lager støtte for, jo mer omskriving blir det den dagen vi endelig må skifte tankesett. Og vi vil en dag måtte gjøre noen endringer.

Domoticz er fortsatt det "beste" valget av system dersom du ønsker:

* web basert oppsett av alt

* tight kode som kan kjøres på hva som helst

* open source

* god støtte for hardware

Dette endres ikke, og er du en som bare installerer og bruker Domoticz så er bekymringene mine langt utenfor det du trenger tenke på. Er du derimot utvikler, eller kanskje en utstyrsleverandør, så er dette ting man må ta med i bagasjen.

Ikke fra UI. Men ser det kunne vært nyttig. 

Legg til libpython3.4-dev så virker Python i beta.

Sitter akkurat å skriver en Python plugin, så... Python virker, men ikke alltid koden min

Ser at du ikke har noe hysterese mellom AV og PÅ. Du risikerer at ovnene går av og på hvert minutt dersom du ikke har et vindu. Eksempelvis ikke skru på ovnene før temp er 2.5 grader under og la dem stå på til temperaturen er 2.5 grader over.

Klikk på Timers på bryteren og legg inn en Fixed timer.

On 31.12.2017 at 09:05, DeVille said:

 hvis det kommer en ny bevegelse innenfor de 5 minuttene går lampa tilsynelatende aldri av.

 

Hva er det jeg har misforstått i logikken her?

 

Den «neste» triggeren så står jo lampen på, og etter 5 minutter vil den da gå tilbake til på.

Nested logikk er menneskelogikk, som skjelden implementeres i programmer.

1 minute ago, Evelen said:

Hmm. så slik jeg ser det har ESP Easy Domoticz integrasjon.

Så dette er mulighetene:

 

Du har jo TCP/UDP så her er det fantasien din som setter begrensninger.

MQTT er greit om det er flere ting som skal dele samme data, men da er senter i hjemmekontrollen din MQTT og alle deler er desentralisert. Det betyr mer intelligens/konfigurasjon i felt, og det gjør systemet mer kompleks i feilsøke i. MQTT øker også latency over andre mer direkte kommunikasjonsmetoder.

2 hours ago, Evelen said:

Kan man styre NodeMcu på en grei måte uten MQTT da?

Hva mener du med å styre?

https://www.domoticz.com/wiki/ESP8266_WiFi_module

https://www.letscontrolit.com/wiki/index.php/Tutorial_Domoticz_Switch

On 29.11.2017 at 20:19, Moskus said:

Bare gi det litt tid.  

Tuklet med smarthus siden 2003. Erfaringen er at gir man det litt tid, så funker det. ;-)

Du kan bruke Blocky for dette. Her aktiveres lys når sensoren ser bevegelse, og når sensoren "går av" står lyset på i 300 sekunder ekstra.

Denne er det fruen som har laget, og synes Blocky er greit for å øke WAF.

15 minutes ago, ronnyandre said:

En grunn til å kjøre MQTT er jo at det er kjapt og enkelt å sette i gang. Det er jo allerede innebygget i Domoticz.

Enda enklere å la være om du ikke har et spesifikt formål med det.

2 minutes ago, xibriz said:

 

MQTT er fint for oss som kjører flere systemer. Da er det lett å pushe all info fra alle systemer ut på MQTT så kan hvilket som helst system hente inn den infoen systemet har lyst på.

Ser den, men MQTT er beregnet på at sensorer snakker direkte med MQTT serveren og noder abonnerer på data og at nodene er desentralisert. Når du bruker systemer som noder i MQTT mener jeg man kanskje bør vurdere om man har rett system til å begynne med. Selv jobber jeg for at Domoticz skal være eneste system i huset, og valget falt på Domoticz nettopp fordi da slapp jeg kjøre flere systemer. Så langt har jeg ingenting som Domoticz ikke takler.

For noe så enkelt som det trådstarter driver med/spør om så er MQTT helt unødvendig.

Istedet? Hvilken funksjon gir MQTT som du ikke har i Domoticz?

Alle sensorer jeg har er representert i Domoticz. Alle brytere jeg har er representert i Domoticz. Domoticz gjør all logging jeg er interessert i. 

Hvorfor skulle man trenge MQTT? Kan ikke se en eneste grunn til å legge til en MQTT i hjemmeautomasjon i et enkelt hus i 2017...