Gå til innhold
ZoRaC

NodeMCU/ESP8266 - hva er det og hva kan det brukes til?

Anbefalte innlegg

53 minutter siden, clio75 skrev:

Har sett litt på arduino plugin og den sier at den kan ha 9 kort. 

Kan noen forklare begrensningen og hva man gjør når man har planlagt 12 ?

 

Mener det kan kjøres Remote.
Da får du så mange du vil utfra hvor mange maskiner du kjører det på.

Litt nysgjerrig 12 stykker, hvorfor det? 

Del dette innlegget


Lenke til innlegg
Del på andre sider
1 minute ago, Odd said:

Litt nysgjerrig 12 stykker, hvorfor det? 

Hvorfor ikke ;)

 

Temker 10++ temp sensorer og i alle fall en "sentral" som styrer litt ut i fra  temperature sensor. 

Så har jeg en del andre ting som jeg kansje skal lage med  nodeMCU 

 

@Actibus Sier du kan ha 30 kort, men finner ikke det i noen beskrivelser/manual. Men jeg finner at mann max kan ha 30 in/out på en device. 

Om 9 stk er en begrensing tror jeg at jeg bruker MYSENSORS.org istede :) 

Del dette innlegget


Lenke til innlegg
Del på andre sider
6 minutter siden, clio75 skrev:

Hvorfor ikke ;)

 

Temker 10++ temp sensorer og i alle fall en "sentral" som styrer litt ut i fra  temperature sensor. 

Så har jeg en del andre ting som jeg kansje skal lage med  nodeMCU 

 

@Actibus Sier du kan ha 30 kort, men finner ikke det i noen beskrivelser/manual. Men jeg finner at mann max kan ha 30 in/out på en device. 

Om 9 stk er en begrensing tror jeg at jeg bruker MYSENSORS.org istede :) 

 

Du kan kjøre flere enn 9 ved å kjøre selve pluginet (exe fila) på en annen enhet og kople det opp som Remote plugin.
Et lite tips ... du kan ha en masse sensorer på en enhet ved å bruke IC2, grensesnittet leses ved at hver sensor får en egen adresse. (ONE wire)

Det er en slags buss hvor du kan henge på X antall sensorer.
 

Endret av Odd

Del dette innlegget


Lenke til innlegg
Del på andre sider
1 hour ago, Actibus said:

Står i linken jeg la ved, man kan ha 30 boards fra v1.0.0.132

@Actibus

Takk, Fant det nå. 
Utvikler har ikke oppdatert manualer og spec i shoppen :)

Del dette innlegget


Lenke til innlegg
Del på andre sider
1 hour ago, Odd said:

Et lite tips ... du kan ha en masse sensorer på en enhet ved å bruke IC2, grensesnittet leses ved at hver sensor får en egen adresse. (ONE wire)

Det er en slags buss hvor du kan henge på X antall sensorer.

Takk for tips :)

Del dette innlegget


Lenke til innlegg
Del på andre sider
On 11/15/2017 at 09:52, cozmo said:

 

Det der ser veldig lovende ut. Ser at folk driver små sensorer i ett års tid med type 3x1.5V batterier.

Jeg fant et design på et ekstremt strømgjerrig sensorkort basert på en ESP-12 (den "beste" versjonen av "ren" ESP8266). Den bruker ikke ESP8266 sin deepsleep-funksjon, men en egen chip som våkner og "skrur på lyset" (enabler en Low-dropout spenningsregulator som forsyner ESP'en) på intervall gitt av en motstand. Den måler også batterispenningen vhja ESP'ens ADC inngang, slik at den kan rapporteres inn.

http://www.kevindarrah.com/wiki/index.php?title=TrigBoard

 

Jeg har tilpasset designet og lagt ut mitt eget kort basert. Bruker nå kortet til bl.a. en temp/hum/lufttrykk sensor som drives av et oppladbart AAA LiFePo4 batteri:

image.png.b30898337689ce6a0179b13f9398ba61.png

Det hele får plass i en 10x6 cm boks.

Ved evt relayout vil jeg nok vurdere å gå over til chip-motstander (SMD), tenker da å bygge inn lading på kortet basert på denne chippen:

https://www.aliexpress.com/item/of-lithium-iron-phosphate-battery-chip-CN3058E-SOP8-absolutely-original/32745932440.html?spm=a2g0s.9042311.0.0.rJoIpA

http://consonance-elec.com/pdf/datasheet/DSE-CN3058E.pdf

 

AAA-batteriet lades nå av en 10x14cm 6V solcelle via en liten LiFePo4 lademodul som jeg har byttet noen chipresistorer på for å redusere ladestrømmen til ca 100 mA (AAA cellen bør ikke lades med mer enn 140 mA).

LiFePo4 er interessant batteriteknologi for 3,3V sensorer. En enkeltcelle LiFePo4 gir 3,2 V spenning ganske flatt helt til den nærmer seg utladet. Max spenning en ESP8266 er speccet for å tåle er 3,6 V, og det passer veldig fint med ladespenningen for LiFePo4. Grafen viser inngangsspenningen sensormodulen har rapportert inn til Domoticz siste tre døgn.Om natta er det batteriet som driver den, om dagen kommer ladespenningen opp. Her er :

image.thumb.png.3a8d069db9d36b02605d44f5f9c188b8.png

Uansett er der en 3,3V LDO spenningsregulator på kortet, så ESP'en ser ikke mer enn 3,3V. Med dette batteriet kunne jeg nok klart meg med en enklere kretsløsning, men dette designet gir fleksibilitet til evt å bruke et LiIon batteri el.l. som har høyere spenning.

  • Like 3
  • Thanks 1

Del dette innlegget


Lenke til innlegg
Del på andre sider

Løst, fant ut av det selv etter en del spekulering.

Kan deles om noen trenger

 

 

Noen som er kompetente på Arduino/NodeMCU koding her?

 

Kunne tenke meg å skrive om denne til å styre 4 rele via MQTT, det meste ligger i fila her men er usikker på hva som må fjernes og endres for å optimere den til mitt bruk.

https://github.com/thehookup/PoolMCU/blob/master/PoolMCU_CONFIGURE.in

Endret av kimstoroy

Del dette innlegget


Lenke til innlegg
Del på andre sider
54 minutter siden, Moskus skrev:

*host* Arduino-plugin */host*

 

Prøvde den, men det var så ustabilt og med en gang den ble disconnected koblet rele 1 inn så en sprinkler i hagen stod på hele natten.

 

Jeg hadde 2 Fibaro Dual Relay som jeg benyttet her tildligere, men det var en kostbar løsning og jeg hadde andre plasser jeg ville benytte disse.

 

Jeg satt in Raspberry med Node Red, det fungerte utmerket via MQTT, men den tar en del plass.

 

Jeg fikk skrevet om en sketch jeg fant, så nå fungerer dette meget bra på NodeMCU via MQTT, samt det er mye billigere enn alternativer over(ca 250 inkl rele og 12v til 5v konverter).

 

Om noen trenger denne kan jeg dele :)

 

 

 

Del dette innlegget


Lenke til innlegg
Del på andre sider



 
Om noen trenger denne kan jeg dele  


Er på trappene til noe tilsvarende. Så om du har lyst til å dele hadde jeg fått litt inspirasjon

Sent from my SM-G930F using Tapatalk

Del dette innlegget


Lenke til innlegg
Del på andre sider

Ikke noe problem, nå har jeg ikke tilgang til den PC før i morgen kveld så får ikke lagt den ut før da. 

  • Like 1

Del dette innlegget


Lenke til innlegg
Del på andre sider
7 timer siden, kimstoroy skrev:

Prøvde den, men det var så ustabilt og med en gang den ble disconnected koblet rele 1 inn så en sprinkler i hagen stod på hele natten.

Øh… jaha? Jeg har kjørt vanningsanlegget med den i noen år nå. Aldri vært et problem her.

 

Og da kan du uansett snu polariteten slik at av faktisk er av. ;) 

Del dette innlegget


Lenke til innlegg
Del på andre sider

OK. Kjører også nyeste beta uten problemer. (Man må selvfølgelig oppdatere sketch'en, men det vet du jo sikkert). :) 

Del dette innlegget


Lenke til innlegg
Del på andre sider

Jeg satte sammen en NodeMCU med en DHT22 som oppdaterer (temperatur og fuktighet) hver time til Thingspeak.com. Jeg henter data fra thingspeak til HomeSeer hjemme. Dermed har jeg kontroll på temperaturen på loftet på landstedet.

Men; i dag merket jeg at NodeMCU'en lager et usikret trådløst nettverk med navn ESP***. Er det en sikkerhetsrisiko? Kan jeg slå det av? Jeg brukte Arduino og wifi-library for å sette opp NodeMCU.

Del dette innlegget


Lenke til innlegg
Del på andre sider
13 timer siden, DiderikFrom skrev:

Men; i dag merket jeg at NodeMCU'en lager et usikret trådløst nettverk med navn ESP***. Er det en sikkerhetsrisiko? Kan jeg slå det av? Jeg brukte Arduino og wifi-library for å sette opp NodeMCU.

 

Det høres ut som en risiko, ja. 

Kan du dele koden du brukte for å sette det opp? Sikkert en smal sak å deaktivere. :) 

Del dette innlegget


Lenke til innlegg
Del på andre sider
1 hour ago, ZoRaC said:

 

Det høres ut som en risiko, ja. 

Kan du dele koden du brukte for å sette det opp? Sikkert en smal sak å deaktivere. :) 

 

 

Ja, meget gjerne! Her er koden. Som du ser, har jeg funnet den på github, men har skrevet noe om fordi den rotet det til med Celsius.

Jeg synes det er rart at NodeMCU'en både kan lage et eget nettverk og være koblet til det trådløse nettet fra 4G-ruteren? 

 

Edit: Når jeg tenker meg om, antar jeg at ESP'en er i rutermodus kun når klienten ikke er tilkoblet (client.stop)? En nødløsning kunne være å flytte delay til før client.stop? Men det beste hadde vært å deaktivere rutermodus.

#include <DHT.h>
#include <ESP8266WiFi.h>

//https://github.com/casper-gh/nodemcu-temperature-sensor/blob/master/thermometer-dht22-thingspeak.ino
 
// replace with your channel's thingspeak API key, 
String apiKey = "***********";
const char* ssid = "**************";
const char* password = "***************";
 
const char* server = "api.thingspeak.com";
#define DHTPIN 4 // D2 pin on Nodemcu
 
DHT dht(DHTPIN, DHT22, 11);
WiFiClient client;

void setup() {                
  Serial.begin(115200);
  delay(10);
  dht.begin();
  
  WiFi.begin(ssid, password);
 
  Serial.println();
  Serial.println();
  Serial.print("Connecting to ");
  Serial.println(ssid);
   
  WiFi.begin(ssid, password);
   
  while (WiFi.status() != WL_CONNECTED) {
    delay(500);
    Serial.print(".");
  }
  Serial.println("");
  Serial.println("WiFi connected");
  
}
  
void loop() {   
  float h = dht.readHumidity();
  float t = dht.readTemperature();
  // Read temperature as Celsius (the default)
  //float t = dht.readTemperature();
  // Read temperature as Fahrenheit (isFahrenheit = true)
  //float f = dht.readTemperature(true);
  if (isnan(h) || isnan(t)) {
    Serial.println("Failed to read from DHT sensor!");
    return;
  }
 
  if (client.connect(server,80)) {  //   "184.106.153.149" or api.thingspeak.com
    String postStr = apiKey;
           postStr +="&field1=";
           postStr += String((float)t);
           postStr +="&field2=";
           postStr += String((float)h);
//String((float)t sends float, and String((int)t sends integer

 
     client.print("POST /update HTTP/1.1\n"); 
     client.print("Host: api.thingspeak.com\n"); 
     client.print("Connection: close\n"); 
     client.print("X-THINGSPEAKAPIKEY: "+apiKey+"\n"); 
     client.print("Content-Type: application/x-www-form-urlencoded\n"); 
     client.print("Content-Length: "); 
     client.print(postStr.length()); 
     client.print("\n\n"); 
     client.print(postStr);
           
 
     Serial.print("Temperature: ");
     Serial.print(t);
     Serial.print(" degrees Celcius Humidity: "); 
     Serial.print(h);
     Serial.println("% send to Thingspeak");    
  }
  client.stop();
   
  Serial.println("Waiting...");    
  // time between updates
  //  delay(120000); // 2 mins
  delay(1800000); // 30 mins
}

 

Endret av DiderikFrom

Del dette innlegget


Lenke til innlegg
Del på andre sider
21 minutter siden, DiderikFrom skrev:

Ja, meget gjerne! Her er koden. Som du ser, har jeg funnet den på github, men har skrevet noe om fordi den rotet det til med Celsius.

 

Jeg tror det løses med å sette dette før wifi.begin():

WiFi.mode(WIFI_STA);

Ref https://github.com/esp8266/Arduino/issues/676

 

Ser også at du har 2 "wifi.begin();", kanskje den ene starter i AP-modus? Ville fjernet den nederste av dem også. :) 

  • Like 1

Del dette innlegget


Lenke til innlegg
Del på andre sider
5 minutes ago, ZoRaC said:

Ser også at du har 2 "wifi.begin();", kanskje den ene starter i AP-modus? Ville fjernet den nederste av dem også. :) 

 

Det har jeg jammen! Det må jeg fjerne,

 

5 minutes ago, ZoRaC said:

 

Jeg tror det løses med å sette dette før wifi.begin():


WiFi.mode(WIFI_STA);

Ref https://github.com/esp8266/Arduino/issues/676

 

Ah, herlig! Det ser veldig riktig ut, jamfør ref. (Det burde jeg jo ha klart å google meg til...)

Tester dette så snart jeg kommer ut til NodeMCU'en.

 

Tusen takk!😃

Del dette innlegget


Lenke til innlegg
Del på andre sider
På 13.6.2018 den 10.15, clio75 skrev:


 

 


Er på trappene til noe tilsvarende. Så om du har lyst til å dele hadde jeg fått litt inspirasjon emoji2.png

Sent from my SM-G930F using Tapatalk
 

 

 

Her er oppsettet mitt på NodeMCU

 

MQTT topic den responderer på:

/Sprinkler/sone1/

/Sprinkler/sone2/

/Sprinkler/sone3/

/Sprinkler/sone4/

 

Den svarer med følgende topic:

/Sprinkler/soneConfirm1/

/Sprinkler/soneConfirm2/

/Sprinkler/soneConfirm3/

/Sprinkler/soneConfirm4/

 

Her benyttes pinne 5-8 på NodeMCU som utganger til Rele, denne kan enkelt utvides til flere soner.

Topic kan endres til noe som passer bedre til ditt prosjekt

 

Her er innholdet i filen som er lastet opp til NodeMCU:

 

#include <PubSubClient.h>
#include <ESP8266WiFi.h>
#include <ArduinoOTA.h>

 

void callback(char* topic, byte* payload, unsigned int length);

 

//EDIT THESE LINES TO MATCH YOUR SETUP
const char* mqtt_server = "ip adr MQTT server";
const char* ssid = "ssid wifi";
const char* password = "Wifi Passord";

 

//EJ: Data PIN Assignment on WEMOS D1 R2 https://www.wemos.cc/product/d1.html
// if you are using Arduino UNO, you will need to change the "D1 ~ D4" with the corresponding UNO DATA pin number

const int switchPin1 = D5;
const int switchPin2 = D6;
const int switchPin3 = D7;
const int switchPin4 = D8;

 

//EJ: These are the MQTT Topic that will be used to manage the state of Relays 1 ~ 4
//EJ: Refer to my YAML component entry
//EJ: feel free to replicate the line if you have more relay switch to control, but dont forget to increment the number suffix so as increase switch logics in loop()

char const* switchTopic1 = "/Sprinkler/sone1/";
char const* switchTopic2 = "/Sprinkler/sone2/";
char const* switchTopic3 = "/Sprinkler/sone3/";
char const* switchTopic4 = "/Sprinkler/sone4/";


WiFiClient wifiClient;
PubSubClient client(mqtt_server, 1883, callback, wifiClient);

void setup() {
  //initialize the switch as an output and set to LOW (off)
  pinMode(switchPin1, OUTPUT); // Relay Switch 1
  digitalWrite(switchPin1, LOW);

  pinMode(switchPin2, OUTPUT); // Relay Switch 2
  digitalWrite(switchPin2, LOW);

  pinMode(switchPin3, OUTPUT); // Relay Switch 3
  digitalWrite(switchPin3, LOW);

  pinMode(switchPin4, OUTPUT); // Relay Switch 4
  digitalWrite(switchPin4, LOW);

  ArduinoOTA.setHostname("Sprinkler NodeMCU"); // A name given to your ESP8266 module when discovering it as a port in ARDUINO IDE
  ArduinoOTA.begin(); // OTA initialization

  //start the serial line for debugging
  Serial.begin(115200);
  delay(100);

  //start wifi subsystem
  WiFi.begin(ssid, password);
  //attempt to connect to the WIFI network and then connect to the MQTT server
  reconnect();

  //wait a bit before starting the main loop
      delay(2000);
}


void loop(){

  //reconnect if connection is lost
  if (!client.connected() && WiFi.status() == 3) {reconnect();}

  //maintain MQTT connection
  client.loop();

  //MUST delay to allow ESP8266 WIFI functions to run
  delay(10);
  ArduinoOTA.handle();
}

void callback(char* topic, byte* payload, unsigned int length) {

  //convert topic to string to make it easier to work with
  String topicStr = topic;
  //EJ: Note:  the "topic" value gets overwritten everytime it receives confirmation (callback) message from MQTT

  //Print out some debugging info
  Serial.println("Callback update.");
  Serial.print("Topic: ");
  Serial.println(topicStr);

   if (topicStr == "/Sprinkler/sone1/")
    {

     //turn the switch on if the payload is '1' and publish to the MQTT server a confirmation message
     if(payload[0] == '1'){
       digitalWrite(switchPin1, HIGH);
       client.publish("/Sprinkler/soneConfirm1/", "1");
       }

      //turn the switch off if the payload is '0' and publish to the MQTT server a confirmation message
     else if (payload[0] == '0'){
       digitalWrite(switchPin1, LOW);
       client.publish("/Sprinkler/soneConfirm1/", "0");
       }
     }

     // EJ: copy and paste this whole else-if block, should you need to control more switches
     else if (topicStr == "/Sprinkler/sone2/")
     {
     //turn the switch on if the payload is '1' and publish to the MQTT server a confirmation message
     if(payload[0] == '1'){
       digitalWrite(switchPin2, HIGH);
       client.publish("/Sprinkler/soneConfirm2/", "1");
       }

      //turn the switch off if the payload is '0' and publish to the MQTT server a confirmation message
     else if (payload[0] == '0'){
       digitalWrite(switchPin2, LOW);
       client.publish("/Sprinkler/soneConfirm2/", "0");
       }
     }
     else if (topicStr == "/Sprinkler/sone3/")
     {
     //turn the switch on if the payload is '1' and publish to the MQTT server a confirmation message
     if(payload[0] == '1'){
       digitalWrite(switchPin3, HIGH);
       client.publish("/Sprinkler/soneConfirm3/", "1");
       }

      //turn the switch off if the payload is '0' and publish to the MQTT server a confirmation message
     else if (payload[0] == '0'){
       digitalWrite(switchPin3, LOW);
       client.publish("/Sprinkler/soneConfirm3/", "0");
       }
     }
     else if (topicStr == "/Sprinkler/sone4/")
     {
     //turn the switch on if the payload is '1' and publish to the MQTT server a confirmation message
     if(payload[0] == '1'){
       digitalWrite(switchPin4, HIGH);
       client.publish("/Sprinkler/soneConfirm4/", "1");
       }

      //turn the switch off if the payload is '0' and publish to the MQTT server a confirmation message
     else if (payload[0] == '0'){
       digitalWrite(switchPin4, LOW);
       client.publish("/Sprinkler/soneConfirm4/", "0");
       }
     }
}


void reconnect() {

  //attempt to connect to the wifi if connection is lost
  if(WiFi.status() != WL_CONNECTED){
    //debug printing
    Serial.print("Connecting to ");
    Serial.println(ssid);

    //loop while we wait for connection
    while (WiFi.status() != WL_CONNECTED) {
      delay(500);
      Serial.print(".");
    }

    //print out some more debug once connected
    Serial.println("");
    Serial.println("WiFi connected");
    Serial.println("IP address: ");
    Serial.println(WiFi.localIP());
  }

  //make sure we are connected to WIFI before attemping to reconnect to MQTT
  if(WiFi.status() == WL_CONNECTED){
  // Loop until we're reconnected to the MQTT server
    while (!client.connected()) {
      Serial.print("Attempting MQTT connection...");

      // Generate client name based on MAC address and last 8 bits of microsecond counter
      String clientName;
      clientName += "esp8266-";
      uint8_t mac[6];
      WiFi.macAddress(mac);
      clientName += macToStr(mac);

      //if connected, subscribe to the topic(s) we want to be notified about
      //EJ: Delete "mqtt_username", and "mqtt_password" here if you are not using any
      if (client.connect((char*) clientName.c_str(),"MQTT brukernavn", "MQTT passord")) {  //EJ: Update accordingly with your MQTT account
        Serial.print("\tMQTT Connected");
        client.subscribe(switchTopic1);
        client.subscribe(switchTopic2);
        client.subscribe(switchTopic3);
        client.subscribe(switchTopic4);
        //EJ: Do not forget to replicate the above line if you will have more than the above number of relay switches
      }

      //otherwise print failed for debugging
      else{Serial.println("\tFailed."); abort();}
    }
  }
}

//generate unique name from MAC addr
String macToStr(const uint8_t* mac){

  String result;

  for (int i = 0; i < 6; ++i) {
    result += String(mac, 16);

    if (i < 5){
      result += ':';
    }
  }
  return result;
}

Del dette innlegget


Lenke til innlegg
Del på andre sider
On 6/18/2018 at 10:39, ZoRaC said:

 

Jeg tror det løses med å sette dette før wifi.begin():


WiFi.mode(WIFI_STA);

Ref https://github.com/esp8266/Arduino/issues/676

 

Ser også at du har 2 "wifi.begin();", kanskje den ene starter i AP-modus? Ville fjernet den nederste av dem også. :) 

 

On 6/18/2018 at 10:47, DiderikFrom said:

 

Det har jeg jammen! Det må jeg fjerne,

 

 

Ah, herlig! Det ser veldig riktig ut, jamfør ref. (Det burde jeg jo ha klart å google meg til...)

Tester dette så snart jeg kommer ut til NodeMCU'en.

 

Tusen takk!1f603.png

 

Da fikk jeg oppdatert NodeMCU'en i dag, og dette funket utmerket!

  • Like 1

Del dette innlegget


Lenke til innlegg
Del på andre sider

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå


  • Lignende innhold

    • Av backspace
      Deler litt bilder og hva jeg gjorde for å få Mitsubishi varmepumpe online med ESP8266 WIFI modul. 
       
      Utgangspunket var å få noe bedre en zxt-120 til å styre varmepumpa og noterte meg at det kan kjøpes diverse plugin moduler fra Mitsubishi for dette (blant annet MelCloud WIFI adapter). Så da tenkte jeg at det måtte være noen terminaler eller plug som en kunne koble seg til. Heldigvis så er det noen som har trakka løypa først så noen kloke hoder har reversert kommunikasjonen på CN105 porten på disse varmepumpene og laget hardware oppsett og software bibliotek for dette; https://github.com/SwiCago/HeatPump. 
       
      I korte trekk så er det en kontakt, CN105, som har seriell kommunikasjon og 5V på ene pinnen så da sier det seg selv at en ESP8266 modull er rette valget her. Denne porten finnes på de fleste Mitsubsihi varmepumper, hvis varmepumpen søtter MelCloud så har den denne kontakten slik jeg har forstått det.
       
      Jeg har en Mitsubishi FD-Heat Kirigamine (MSZ-35FD).

       
      Så da er det bare å trekke ut strømkontakten til varmepumpa og åpne opp. Finner hovedkortet og i mitt tilfelle så må en ta ut flere kontakter for å få ut hovedkortet. CN105 kontakten ser ut til å være brun i det fleste tilfeller. Den har 5 pinner.

      Type kontakt som passer er PAP-05V-S, jeg kjøpte min fra Elfa: "Krympehus Poles 5 300-21-706" og klemmkontaker som passer "Klemkontakt Hunn 300-21-733". Bruker kontakter 2-5 (TX,RX,5V,GND).
       

      Siden jeg har min pumpe opp under taket laget jeg en lang ledning slik at jeg kan ha kontroll modul på toppen. Laget et lite hakk i kabinett for ledning ut. Har en liten nedfelt "hylle" på toppen hvor jeg til slutt skal ha kontrolleren med borrelås er planen.

       
      Sjekket at det var 5V på plus leding etter mod (NB! pinne 1 har 12V) så en slipper uønsket grill party.

       
      Så jeg tok det jeg fant av komponenter i skuffen og hev det på et breadbord med en ESP8266-01 etter beste evne. 

       
      Jeg har vært igjennom Arduino skolen (kit) så jeg hadde en "programmerings rig" for ESP8266-01 liggende så det passet bra for dette prosjektet (men nodemcu ESP8266-12) virker også fint for dette (den enkle varianten å gjøre dette på).
       

       
      Og så laget jeg et breadboard #2 som ble montert på varmepumpen for testing. Flyttet da bare ESP'en frem og tilbake når kode måtte oppdateres. 

       
      Jeg brukte Arduino IDE med ESP8266 og PubSubClient MQTT biblioteker. På Homeseer brukte jeg mcsMQTT plugin da denne parser JSON direkte og lager egne devicer for hver parameter i JSON strengen. Tick av "A" for de lesingene du ønsker og den lager devicer i Homeseer.
       
      Modifiserte MQTT eksempelet med fixed IP og laget egne MQTT subscriptions for de ulike kommandoene da mcsMQTT plugin for Homeseer ikke sender JSON for kommandoer. Noter de ulike topics f.eks heatpump/set/fan nedenfor i settings for mcsMQTT som en må sette for hver device som skal sende data. I utgangspunktet er eksempel kode på ESP'en satt opp med å motta alle parameter på same topic, må da sende MQTT payload som JSON streng f.eks {temperature: 24}. Så derfor tok jeg en "kjapp" update med egen topic for hver setting og tar da bare verdi rett fra device i homeseer som payload for raskt få det til å virke. Men her kan en lage det som en vil uansett.

       
      Jeg la til disse som nye topics i .h filen, måtte også oppdatere litt i "void mqttCallback(...) samt registere de nye MQTT topics.
       
      // new topics for Homeseer/mcsMQTT const char* heatpump_set_power_topic = "heatpump/set/power"; const char* heatpump_set_mode_topic = "heatpump/set/mode"; const char* heatpump_set_temperature_topic = "heatpump/set/temperature"; const char* heatpump_set_fan_topic = "heatpump/set/fan"; const char* heatpump_set_vane_topic = "heatpump/set/vane"; const char* heatpump_set_widevane_topic = "heatpump/set/widewane";  
      Får da hver gang det er en forandring  på varmepumpe settings (enten via MQTT eller fjernkontroll) så oppdateres MQTT topic "heatpump" som JSON streng:
       
      {"power":"ON","mode":"HEAT","temperature":25,"fan":"2","vane":"SWING","wideVane":"SWING"}
       
      Ellers leser den temperatur hver 60 sekunder (kan justeres i kode) på topic "heatpump/status:
       
      {"roomTemperature":25,"operating":true}
       

       
      ...og det var en kort update på hvordan jeg fikk min varmepumpe online 😄
       
       
    • Av ZoRaC
      @Moskus har et script som holder orden på offentlige fridager:
       
      Dessverre holder ikke denne styr på dager du er hjemme utover de offentlige fridagene - sykedag, innklemt dag, vinterferie, høstferie, påskeferie, sommerferie, osv, osv. Dvs at hvis du bruker dette til å styre senking av temperatur når du er på jobb, så blir det veldig kaldt disse dagene!  
       
      Min løsninger er å lage en egen Google Calendar for "huset", som jeg leser av via Google sitt API (med PHP) og oppdaterer HomeSeer utifra det.
      Jeg kjører på Linux, men ser ingenting i veien for at samme løsning kan kjøres på Windows.  
       
      PS: 
      Dette bruker PHP fra kommandolinje, så man trenger ikke kjøre en webserver med PHP-støtte eller åpne noen porter i brannmurer, osv.  
       
      1. Aller først, implementer @Moskus sitt script fra lenken over og sjekke at det virker.
       
      2. Deretter er det bare følg denne guiden og se at du får tilgang til å lese ut data fra din primære Google-kalender:
      https://developers.google.com/google-apps/calendar/quickstart/php
       
      3. Så lager du en egen "hus-kalender".
      Gå deretter inn på innstillinger for kalenderen og finn kalender-ID'en:


      4. Legg inn dette scriptet som "HomeSeer.php" (og rediger de 4 øverste linjene):
      5. Legg til et event i "hus-kalenderen" og sjekk at den listet opp når du nå kjører "php HomeSeer.php".
       
      6. Sett opp følgende event:

       
      Da skal "fridag"-devicen oppdateres seg basert på kalenderen i tillegg til faste fridager fra scriptet til @Moskus.  
    • Av ZoRaC
      Det er et gjentagende problem dette med å assosiere forskjellige noder og at det ikke fungerer, ofte er årsaken secure/nonsecure-inkludering av de to nodene. 
       
      Her kommer en kort oppsummering, som kan gjøre feilsøkingen lettere:
      1. To noder som skal assosieres må (som hovedregel) begge være inkludert enten secure eller nonsecure. Unntaket er noen enheter som kan inkluderes secure og sette en parameter som sier den skal sende kommandoer til assosierer enheter nonsecure (f.eks parameter 27 på Fibaro Dimmer 2). 
       
      2. Hvis en enhet bare støtter nonsecure og du velger "Add/include node", så vil den bli lagt til nonsecure!
       
      3. Hvis en enhet støtter secure og du velger "Add/include node", så vil den bli lagt til secure!
       
      4. I følge HomeSeer-support så er det ikke mulig å bruke fremgangsmåten nedenfor likevel, en enhet som støtter "secure" vil vise "secure"-feltene uansett om den er lagt til "secure" eller "nonsecure", men har ikke testet og verifisert om det stemmer eller ikke. 
      4. Her er alternativ måte å sjekke på:
      4a. https://hs3-ip/ZWaveConfig
      4b. "Log send and receive device information to the HomeSeer log"
      4c. Slå av/på noden
      4d. Sjekk loggen:
      Hos meg er node 17 en Fibaro Dimmer 2 og node 35 er en Fibaro RGBW.
       
      5. Du kan sjekke om en node støtter secure i manualen til den (i noen tilfeller). Se etter "COMMAND_CLASS_SECURE".
      Om det ikke står i manualen, kan du søke opp produktet her:
      https://products.z-wavealliance.org/regions/1/categories
      Inne på produktsiden kan du klikke på "View command classes" nederst på siden og se etter "security". 
    • Av Moskus
      Mer Z-wave!
      Nå begynner det å bli hakket mer avansert. Vi retter et par små-feil, og vi setter opp litt assosiasjon.
       
      HomeSeer og Z-wave
      Øverst til høyre på "Device Management"-siden finner du en blå knapp med et antenne-symbol på. Det er Polling. Trykker du på den vil HomeSeer spørre nodene du ser om hvilken status de har.
       
      Hvis du kikker litt nærmere på en Fibaro Dimmer 2 node, vil du se at et par ekstra enheter som ikke gir fornuftig informasjon, samt en ekstra "dimmer" (som gjør at status ikke blir oppdatert hvis du trykker på en fysisk knapp). Jaha, men hvorfor fikk vi de?
       
      Problemet er egentlig ikke HomeSeer. Det er hvordan Fibaro har valgt å skrive firmwaren sin. Noen gateway'er og programmer har et grunnleggende Z-wave-oppsett i bunn, men legger til støtte enhet for enhet. Problemet med en slik tilnærming er at det krever mye energi, man får et begrenset utvalgt enheter, og en gammel enhet med ny firmware må testes på nytt fordi oppdateringer kan fikse en ting men ødelegge for noe annet.
       
      HST går istedenfor bredt ut. HomeSeer sin "policy" er at hvis en enhet er sertifisert ihht. Z-wave (Plus) så skal den være støttet i HomeSeer. Men støtten er dermed avhengig av produsenten. Hvis de har gjort alt riktig uten å gjøre noen "smarte tilpasninger" (for eksempel for å kunne bli integrert "bedre" i sin egen gateway enn andre) så går det glatt inn i HomeSeer. Fibaro lager god hardware, men firmwaren er (etter min mening) ikke like god. Men Fibaro er langt fra de eneste som har dette problemet.
       
       
       
      Feilretting
      Først retter vi på assosiasjoner slik at HomeSeer og dimmeren snakker sammen. For å konfigurere en node, må vi finne "root". I de fleste tilfeller finner vi root'en øverst i node-gruppa, med tannhjul-symbolet og teksten "No Status" (root har normalt ingen status). Trykk på "Fibaro Switch Multilevel", og gå til tab'en "Z-wave". Du ser noe slikt:
       

       
      Trykk på den gule pilen foran "Associations". Hos meg ser det da slik ut:
       

       
      Vi vil ikke videresende endpoint-informasjon, så fjerner vi disse. Så må vi legge til nye. For Z-wave Plus skal det i utgangspunktet holde å assosiere Group 1 til HomeSeer (som alltid har ID = 1), men HS liker å legge seg selv til i alle grupper. Vi kan gjøre det her. Først velger vi Gruppen, så noden (nå kun node 1) og så trykker vi på "Add". Merk at vi ikke skal velge endpoint.
       
      Det gjør vi for alle gruppene, og Dimmer 2 har 5. Etter å ha lagt til alle skal det se slik ut:
       

       
       
      EDIT: Du trenger muligens ikke slette disse devicene lenger, de kan faktisk gi nyttig informasjon. Det er avhengig av hvilken firmware du har på Dimmeren, og hvilken versjon av Z-wave plugin'en du kjører. Det vil klare seg med å bare skjule (velg "Hide") dem istedenfor å slette dem.
      Så sletter vi "devicer" ikke gir mening. Du kan slette "Heat Notification", "Power Management Notification", "System Notification" og "Switch Multilevel 2". Det gjør vi enklest ved å velge dem med avkryssingsboksene til venstre, og velger "Delete" i nedtrekksmenyen øverst til venstre.
       

       
      Sånn! Nesten ferdig!
       
      Hos meg manglet "Switch Multilevel 1" (av for meg uforståelige grunner) kommandoen "On Last Level". "On" betyr "dim til 100%", mens "On Last Level" betyr "dim til det nivået dimmeren var satt til sist", og er dermed ganske hendig. Hvis denne ikke dukker opp hos deg, er det heldigvis enkelt å legge til.
       
      Trykk på den blå linken til "Switch Multilevel 1" og gå til tab'en "Status Graphics". Denne vil sannsynligvis se slik ut:
       

       
      Vi skal legge til en entalls verdi/kommando og trykker på knappen "Add Single Value". Value settes til "255", status tekst endres fra "Change me" til "On Last Level", og i nedtrekksmenyen under velger du "On Alternate". Row settes til "1" og Column til "3".
       
      Så blar vi  helt nederst til siden og trykker "Done".
       
      For sikkerhets skyld trykker vi på "Switch Multilevel 1", går til "Status Graphics"-tab'en og verifiserer at verdiene ser slik ut. (Dette har aldri vært et problem med PC-versjonen, men Zee2 tullet litt med dette før versjon .270. Burde være fikset nå, men vi sjekker likevel).
       

       
      Nå er alt vel!
      Når du har gjort dette et par ganger, vil det gå raskt etterpå. Det tar ca. 30 sekunder (avhengig hvor lang tid assosiasjonene tar).
       
      ... og det er bare å fortsette å inkludere noder. Under er en eldre Qubino dimmer inkludert.
       
       
       
      Parametere
      En node har sannsynligvis flere innstillinger enn de som er tilgjengelige via et brukergrensesnitt. Dette er typisk for verdier som ikke behøves å justere så ofte. Eksempler er temperatur-kalibrering, følsomhet for en bevegelsessensor, hvor lang tid en dimmer bruker på dimmer opp/ned lyset, og så videre.
       
      Slike ting justeres vanligvis med en parameter. En parameter består et parameter-nummer (et heltall mellom 0 og 255), samt en verdi (1 byte, 2 eller 4 bytes). Men det er ingen fastsatte regler om hva de forskjellige parameter-nummerne er, så det må vi slå opp i manualen. Det er også viktig å bruke manualen som fulgte med i boksen til produktet du kjøpte, for andre firmware-versjoner kan faktisk ha andre parametere.
       
      Fibaro Dimmer 2 har en snedig funksjon som heter "auto calibrate". Den sjekker hvordan lyskilden som er koblet til oppfører seg ved forskjellige lysstyrker, og tar så hensyn til dette når dimmeren senere skal dimme lyset. Den starter automatisk når du kobler opp dimmeren første gang, men man kan også tvinge den i gang senere (og det er praktisk!) ved å sette sette parameter 13 til 1 (eller 2 hvis du bruker en Bypass).
       
      Igjen går vi til root, og videre til Z-wave. Vi trykker på den gule pilen foran "Settings", og fortsetter med å velge parameter 13, og sette verdien til 1. Slik:
       

       
      Så er det bare å trykke på "Set"-knappen, og autokalibreringsfunksjonen starter.
       
      Merk:
      Hvis du allerede har satt en parameter, men ikke husker hva du satte den til, kan du velge parameternummeret og la "Value" være blankt. Trykker du da på "Set" vil HomeSeer hente verdien du har satt. Hvis du ikke har satt en verdi, vil du sannsynligvis få teksten "ERROR". Da er det standardverdien som gjelder (så du må slå opp i manualen).
       
       
      Andre noder har et ferdig oppsett slik at du enkelt forstår hvilke parametere du justerer. De fleste noder kommer uten dette ferdige oppsettet (og her skulle jeg ønske HomeSeer kunne bruke et XML-oppsett eller noe slikt, det er ikke "rocket science" å skrive en tekst og et tilhørende parameter-nummer). Se skjult tekst for langt bilde.
       
       
      Parametere har potensiale til å kunne skape kaos av en ellers fungerende node, så vær litt forsiktig...  
       
       
      Assosiasjon
      Kort fortalt lar assosiasjon en node styre en annen. En node kan ha forskjellige grupper ("Groups"), som gjør ulike ting. F.eks. en bevegelsessensor kan ha en gruppe for å skru av/på andre noder basert på bevegelse og en annen gruppe for å skru av/på andre noder basert på lys.
       
      Fibaro-dimmerne har to brytere. Bryter 1 (navngitt "S1",) styrer først og fremst lyset dimmeren er koblet til. Men bryter 2 ("S2") bruker assosiasjon til å styre andre lys. Jeg har satt det opp slik at bryter 2 i stua styrer kjøkkenlyset og motsatt.
       
      For Z-wave Plus er alltid "Group 1" det som er kalt "lifeline". Gruppe 1 skal alltid assosieres med master controller, og der blir informasjon mellom noden og master utvekslet (som f.eks. "Instant Status" som forteller HomeSeer at noden har blitt skrudd på eller av via knapp eller andre assosiasjoner). I "gamle dager" var det ingen standard for lifeline, "Instant Status" var ikke engang vanlig. Versjon 1 av dimmerne fra Fibaro og Qubino brukte da den siste gruppen til lifeline (hhv Group 3 og Group 4).
       
      S2 i stua styrer kjøkkenlyset (merk at det er snakk om Dimmer 1, ikke 2):

       
      S2 på kjøkkenet styrer lyset i stua:

       
      Merknad 1:
      I bildet over når under overskriften "Feilretting" ser du at HomeSeer er assosiert til alle gruppene. Dette skal egentlig ikke være nødvendig! Z-wave Plus bruker som nevnt Group 1 som lifeline. Det skal være tilstrekkelig å kun assosiere Group 1 til HS3.
       
      Merknad 2:
      Ved bruk av assosiasjon er det også viktig å lese bruksanvisningen. For eksempel har Dimmer 2, som poengtert her, to grupper knyttet til knapp S1. Gruppe 2 og Gruppe 3 styres fra S1: Gruppe 2 sender kun On/Off mens Gruppe 3 også kan dimme. Det samme for knapp S2, men da er gruppene hhv 4 og 5.
       
       
      Includering secure/non-secure
      Alle dørlåser med Z-wave må bruke "secure" inkludering. Dette fordi kommunikasjonen mellom HomeSeer og dørlåsen skal krypteres, og som et sikkerhetstiltak må avstanden mellom controlleren og noden være 60 cm eller mindre når du setter den opp første gang. Det gjør det litt kronglete å sette opp en allerede montert dørlås, men det er kjekt å vite at kommunikasjonen er kryptert. Og jeg vil si det er kjekt med kryptering (men ikke nødvendig) for noder som f.eks. styrer ovner.
       
      Men for eksempelvis dimmere og bevegelsessensorer er det min personlige mening at kryptering er litt overkill. Kryptering med Z-wave har noen ulemper:
      Som nevnt må avstanden mellom controller og node være liten. For en montert dimmer kan dette by på problemer. Det gir mer kommunikasjon og dermed mer belastning på Z-wave nettverket For batteridrevne noder, som f.eks. en bevegelsessensor eller magnetsensor, betyr kryptering vesentlig høyere batteribruk.  
      Men er det enkelt å oppfylle kravene til kryptering og det er enheter som ikke bruker batteri, er det ikke noe problem å bruke kryptering.  
       
       
      Z-Health
      I del 3 ble det nenvt at optimalisering er veldig viktig. Z-Health er en funksjon som kan gjøre dette for deg.
      Gå til Plugins → Z-wave → Controller Management, og utvid den øverste gule menyen, med navnet "Z-Wave Networks and Options".
       
      Helt til høyre finner du opsjonen for Z-Health. Setter du den på, får du mulighet til å justere klokkeslettet den skal kjøre på. Velg et klokkeslett som huset vanligvis ikke er aktivt, optimalisering gjør at vanlig Z-wave-trafikk blir stanset midlertidig. F.eks. mellom 01:30 og 05:00.
       
      Z-wave nettverket bør ikke optimaliseres hvis det ikke er noe å optimalisere, det kan gi flere problemer enn det løser. Men hvis du flytter litt rundt på noder eller plugger inn eller ut noder regelmessig (som du egentlig ikke bør gjøre), så kan Z-Health være en grei måte å opprettholde et friskt nettverk på.
       

       
       
      Oppsummering
      I del 3 la vi til et interface og inkluderte noder i nettverket, og optimaliserte nettverket. Denne gangen har vi rettet noen feil med oppsettet, vi kan justere parametere og bruke assosiasjoner for å kontrollere noder.
       
      Tidligere har vi sett på valg mellom de ulike versjonene (del 1) og hvordan man setter det opp (del 2). I del 5 skal vi se nærmere på bruk av 433MHz-teknologi med RFXtrx433, og i del 6 det skal vi behandle alle enhetene våre, navngi dem, sortere, og se litt nærmere på mulighetene vi har i grensesnittet.
       
      Spørsmål? Kommentarer?
      Gi lyd i kommentarfelet!  
       
       

      Vis full oppføring
    • Av Moskus
      Mer Z-wave!
      Nå begynner det å bli hakket mer avansert. Vi retter et par små-feil, og vi setter opp litt assosiasjon.
       
      HomeSeer og Z-wave
      Øverst til høyre på "Device Management"-siden finner du en blå knapp med et antenne-symbol på. Det er Polling. Trykker du på den vil HomeSeer spørre nodene du ser om hvilken status de har.
       
      Hvis du kikker litt nærmere på en Fibaro Dimmer 2 node, vil du se at et par ekstra enheter som ikke gir fornuftig informasjon, samt en ekstra "dimmer" (som gjør at status ikke blir oppdatert hvis du trykker på en fysisk knapp). Jaha, men hvorfor fikk vi de?
       
      Problemet er egentlig ikke HomeSeer. Det er hvordan Fibaro har valgt å skrive firmwaren sin. Noen gateway'er og programmer har et grunnleggende Z-wave-oppsett i bunn, men legger til støtte enhet for enhet. Problemet med en slik tilnærming er at det krever mye energi, man får et begrenset utvalgt enheter, og en gammel enhet med ny firmware må testes på nytt fordi oppdateringer kan fikse en ting men ødelegge for noe annet.
       
      HST går istedenfor bredt ut. HomeSeer sin "policy" er at hvis en enhet er sertifisert ihht. Z-wave (Plus) så skal den være støttet i HomeSeer. Men støtten er dermed avhengig av produsenten. Hvis de har gjort alt riktig uten å gjøre noen "smarte tilpasninger" (for eksempel for å kunne bli integrert "bedre" i sin egen gateway enn andre) så går det glatt inn i HomeSeer. Fibaro lager god hardware, men firmwaren er (etter min mening) ikke like god. Men Fibaro er langt fra de eneste som har dette problemet.
       
       
       
      Feilretting
      Først retter vi på assosiasjoner slik at HomeSeer og dimmeren snakker sammen. For å konfigurere en node, må vi finne "root". I de fleste tilfeller finner vi root'en øverst i node-gruppa, med tannhjul-symbolet og teksten "No Status" (root har normalt ingen status). Trykk på "Fibaro Switch Multilevel", og gå til tab'en "Z-wave". Du ser noe slikt:
       

       
      Trykk på den gule pilen foran "Associations". Hos meg ser det da slik ut:
       

       
      Vi vil ikke videresende endpoint-informasjon, så fjerner vi disse. Så må vi legge til nye. For Z-wave Plus skal det i utgangspunktet holde å assosiere Group 1 til HomeSeer (som alltid har ID = 1), men HS liker å legge seg selv til i alle grupper. Vi kan gjøre det her. Først velger vi Gruppen, så noden (nå kun node 1) og så trykker vi på "Add". Merk at vi ikke skal velge endpoint.
       
      Det gjør vi for alle gruppene, og Dimmer 2 har 5. Etter å ha lagt til alle skal det se slik ut:
       

       
       
      EDIT: Du trenger muligens ikke slette disse devicene lenger, de kan faktisk gi nyttig informasjon. Det er avhengig av hvilken firmware du har på Dimmeren, og hvilken versjon av Z-wave plugin'en du kjører. Det vil klare seg med å bare skjule (velg "Hide") dem istedenfor å slette dem.
      Så sletter vi "devicer" ikke gir mening. Du kan slette "Heat Notification", "Power Management Notification", "System Notification" og "Switch Multilevel 2". Det gjør vi enklest ved å velge dem med avkryssingsboksene til venstre, og velger "Delete" i nedtrekksmenyen øverst til venstre.
       

       
      Sånn! Nesten ferdig!
       
      Hos meg manglet "Switch Multilevel 1" (av for meg uforståelige grunner) kommandoen "On Last Level". "On" betyr "dim til 100%", mens "On Last Level" betyr "dim til det nivået dimmeren var satt til sist", og er dermed ganske hendig. Hvis denne ikke dukker opp hos deg, er det heldigvis enkelt å legge til.
       
      Trykk på den blå linken til "Switch Multilevel 1" og gå til tab'en "Status Graphics". Denne vil sannsynligvis se slik ut:
       

       
      Vi skal legge til en entalls verdi/kommando og trykker på knappen "Add Single Value". Value settes til "255", status tekst endres fra "Change me" til "On Last Level", og i nedtrekksmenyen under velger du "On Alternate". Row settes til "1" og Column til "3".
       
      Så blar vi  helt nederst til siden og trykker "Done".
       
      For sikkerhets skyld trykker vi på "Switch Multilevel 1", går til "Status Graphics"-tab'en og verifiserer at verdiene ser slik ut. (Dette har aldri vært et problem med PC-versjonen, men Zee2 tullet litt med dette før versjon .270. Burde være fikset nå, men vi sjekker likevel).
       

       
      Nå er alt vel!
      Når du har gjort dette et par ganger, vil det gå raskt etterpå. Det tar ca. 30 sekunder (avhengig hvor lang tid assosiasjonene tar).
       
      ... og det er bare å fortsette å inkludere noder. Under er en eldre Qubino dimmer inkludert.
       
       
       
      Parametere
      En node har sannsynligvis flere innstillinger enn de som er tilgjengelige via et brukergrensesnitt. Dette er typisk for verdier som ikke behøves å justere så ofte. Eksempler er temperatur-kalibrering, følsomhet for en bevegelsessensor, hvor lang tid en dimmer bruker på dimmer opp/ned lyset, og så videre.
       
      Slike ting justeres vanligvis med en parameter. En parameter består et parameter-nummer (et heltall mellom 0 og 255), samt en verdi (1 byte, 2 eller 4 bytes). Men det er ingen fastsatte regler om hva de forskjellige parameter-nummerne er, så det må vi slå opp i manualen. Det er også viktig å bruke manualen som fulgte med i boksen til produktet du kjøpte, for andre firmware-versjoner kan faktisk ha andre parametere.
       
      Fibaro Dimmer 2 har en snedig funksjon som heter "auto calibrate". Den sjekker hvordan lyskilden som er koblet til oppfører seg ved forskjellige lysstyrker, og tar så hensyn til dette når dimmeren senere skal dimme lyset. Den starter automatisk når du kobler opp dimmeren første gang, men man kan også tvinge den i gang senere (og det er praktisk!) ved å sette sette parameter 13 til 1 (eller 2 hvis du bruker en Bypass).
       
      Igjen går vi til root, og videre til Z-wave. Vi trykker på den gule pilen foran "Settings", og fortsetter med å velge parameter 13, og sette verdien til 1. Slik:
       

       
      Så er det bare å trykke på "Set"-knappen, og autokalibreringsfunksjonen starter.
       
      Merk:
      Hvis du allerede har satt en parameter, men ikke husker hva du satte den til, kan du velge parameternummeret og la "Value" være blankt. Trykker du da på "Set" vil HomeSeer hente verdien du har satt. Hvis du ikke har satt en verdi, vil du sannsynligvis få teksten "ERROR". Da er det standardverdien som gjelder (så du må slå opp i manualen).
       
       
      Andre noder har et ferdig oppsett slik at du enkelt forstår hvilke parametere du justerer. De fleste noder kommer uten dette ferdige oppsettet (og her skulle jeg ønske HomeSeer kunne bruke et XML-oppsett eller noe slikt, det er ikke "rocket science" å skrive en tekst og et tilhørende parameter-nummer). Se skjult tekst for langt bilde.
       
       
      Parametere har potensiale til å kunne skape kaos av en ellers fungerende node, så vær litt forsiktig...  
       
       
      Assosiasjon
      Kort fortalt lar assosiasjon en node styre en annen. En node kan ha forskjellige grupper ("Groups"), som gjør ulike ting. F.eks. en bevegelsessensor kan ha en gruppe for å skru av/på andre noder basert på bevegelse og en annen gruppe for å skru av/på andre noder basert på lys.
       
      Fibaro-dimmerne har to brytere. Bryter 1 (navngitt "S1",) styrer først og fremst lyset dimmeren er koblet til. Men bryter 2 ("S2") bruker assosiasjon til å styre andre lys. Jeg har satt det opp slik at bryter 2 i stua styrer kjøkkenlyset og motsatt.
       
      For Z-wave Plus er alltid "Group 1" det som er kalt "lifeline". Gruppe 1 skal alltid assosieres med master controller, og der blir informasjon mellom noden og master utvekslet (som f.eks. "Instant Status" som forteller HomeSeer at noden har blitt skrudd på eller av via knapp eller andre assosiasjoner). I "gamle dager" var det ingen standard for lifeline, "Instant Status" var ikke engang vanlig. Versjon 1 av dimmerne fra Fibaro og Qubino brukte da den siste gruppen til lifeline (hhv Group 3 og Group 4).
       
      S2 i stua styrer kjøkkenlyset (merk at det er snakk om Dimmer 1, ikke 2):

       
      S2 på kjøkkenet styrer lyset i stua:

       
      Merknad 1:
      I bildet over når under overskriften "Feilretting" ser du at HomeSeer er assosiert til alle gruppene. Dette skal egentlig ikke være nødvendig! Z-wave Plus bruker som nevnt Group 1 som lifeline. Det skal være tilstrekkelig å kun assosiere Group 1 til HS3.
       
      Merknad 2:
      Ved bruk av assosiasjon er det også viktig å lese bruksanvisningen. For eksempel har Dimmer 2, som poengtert her, to grupper knyttet til knapp S1. Gruppe 2 og Gruppe 3 styres fra S1: Gruppe 2 sender kun On/Off mens Gruppe 3 også kan dimme. Det samme for knapp S2, men da er gruppene hhv 4 og 5.
       
       
      Includering secure/non-secure
      Alle dørlåser med Z-wave må bruke "secure" inkludering. Dette fordi kommunikasjonen mellom HomeSeer og dørlåsen skal krypteres, og som et sikkerhetstiltak må avstanden mellom controlleren og noden være 60 cm eller mindre når du setter den opp første gang. Det gjør det litt kronglete å sette opp en allerede montert dørlås, men det er kjekt å vite at kommunikasjonen er kryptert. Og jeg vil si det er kjekt med kryptering (men ikke nødvendig) for noder som f.eks. styrer ovner.
       
      Men for eksempelvis dimmere og bevegelsessensorer er det min personlige mening at kryptering er litt overkill. Kryptering med Z-wave har noen ulemper:
      Som nevnt må avstanden mellom controller og node være liten. For en montert dimmer kan dette by på problemer. Det gir mer kommunikasjon og dermed mer belastning på Z-wave nettverket For batteridrevne noder, som f.eks. en bevegelsessensor eller magnetsensor, betyr kryptering vesentlig høyere batteribruk.  
      Men er det enkelt å oppfylle kravene til kryptering og det er enheter som ikke bruker batteri, er det ikke noe problem å bruke kryptering.  
       
       
      Z-Health
      I del 3 ble det nenvt at optimalisering er veldig viktig. Z-Health er en funksjon som kan gjøre dette for deg.
      Gå til Plugins → Z-wave → Controller Management, og utvid den øverste gule menyen, med navnet "Z-Wave Networks and Options".
       
      Helt til høyre finner du opsjonen for Z-Health. Setter du den på, får du mulighet til å justere klokkeslettet den skal kjøre på. Velg et klokkeslett som huset vanligvis ikke er aktivt, optimalisering gjør at vanlig Z-wave-trafikk blir stanset midlertidig. F.eks. mellom 01:30 og 05:00.
       
      Z-wave nettverket bør ikke optimaliseres hvis det ikke er noe å optimalisere, det kan gi flere problemer enn det løser. Men hvis du flytter litt rundt på noder eller plugger inn eller ut noder regelmessig (som du egentlig ikke bør gjøre), så kan Z-Health være en grei måte å opprettholde et friskt nettverk på.
       

       
       
      Oppsummering
      I del 3 la vi til et interface og inkluderte noder i nettverket, og optimaliserte nettverket. Denne gangen har vi rettet noen feil med oppsettet, vi kan justere parametere og bruke assosiasjoner for å kontrollere noder.
       
      Tidligere har vi sett på valg mellom de ulike versjonene (del 1) og hvordan man setter det opp (del 2). I del 5 skal vi se nærmere på bruk av 433MHz-teknologi med RFXtrx433, og i del 6 det skal vi behandle alle enhetene våre, navngi dem, sortere, og se litt nærmere på mulighetene vi har i grensesnittet.
       
      Spørsmål? Kommentarer?
      Gi lyd i kommentarfelet!  
       
       
×