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

433 sensorer til Z-Wave


Anbefalte innlegg

Hei,

 

Er litt inne på tanken rundt å lage en Z-Wave dongle som konverterer enkle sensorer som oregon (værsensor), Nexa komponenter etc til Z-Wave.

I praksis blir det en liten USB dongle som du putter i en USB strømforsyning. Den vil deretter formidle dataene fra disse sensorene til Z-Wave. Støtte for firmware oppgradering vil gjøre at man kan utvide med flere sensorer på sikt.

Er dette noe noen kunne tenke seg å se utviklet ?

Planen er å bygge videre på det jeg har gjort med Z-Wave Snifferen (https://www.suphammer.net/zwave_sniffer/).

 

Mvh

Jon

 

Endret av suphammer
Legger ved referanse
Lenke til kommentar
Del på andre sider

Z-wave-sniffing er teknisk sett mulig, men dette er jo mye letter løsbart med å ha en controller som støtter begge deler.

 

Ikke for å punktere prosjektet ditt fullstendig, men er det egentlig behov for slikt? Hvordan har du tenkt å "formidle dataene til Z-wave"? Det er jo ikke akkurat som om det bare er å distribuere data som UDP.

Lenke til kommentar
Del på andre sider

Den største utfordringen jeg ser for meg er alle de forskjellige protokollene på 433 MHz. Man ser jo hvordan det ser ut i RFXCOM-plugin. Noen må jo utvikle/videreutvikle støtte for de forskjellige protokollene etter hvert. 

 

Ellers enig med @Moskus - man kan jo løse det med et eget interface og da er det jo likegyldig for systemet om det er 433 eller z-wave. 

Endret av ZoRaC
Lenke til kommentar
Del på andre sider

3 minutter siden, ZoRaC skrev:

Den største utfordringen jeg 

Drukket Yoda saften idag?

 

(Regner med du postet for tidlig ?)

 

 

Men en fordel jeg kan se om å få 433Mhz over på Z-wave kontra en egen kontroller er vel at da kan en få "lenger rekkevidde" på 433mhz produkter uten å bruke rpi+kontroller over nettverk, en annen sak er vel hvor mye trafikk det da vil bli på z wave nettverket da 433mhz produkter gjerne oppdaterer seg til faste intervaller uten muligheter for å justere det.

Endret av Hr Kotelett
Lenke til kommentar
Del på andre sider

2 minutter siden, Hr Kotelett skrev:

Drukket Yoda saften idag?

 

(Regner med du postet for tidlig ?)

 

Tastaturet minimerte seg og da lå post-knappen akkurat der den bokstaven jeg skulle trykke på lå. :P Sitter ellers å nyter en "Mack Freeze", men man tåler ganske mange av dem! ;) 

  • Like 1
Lenke til kommentar
Del på andre sider

Hei Moskus! Takk for tilbakemeldingene. Se svar under.

1 time siden, Moskus skrev:

Z-wave-sniffing er teknisk sett mulig, men dette er jo mye letter løsbart med å ha en controller som støtter begge deler.

Jeg har laget en lavnivå Z-Wave stack som kjører inne i en liten USB Stick med en veldig fleksibel radio og en mikroprosessor uten bruk av Sigma Design sin egen Z-Wave radio.

Denne klarer idag å lytte til radio å presentere Z-Wave pakkene dekodet eller evt i råformat via serial port over USB uten bruk av ekstern software. Denne enheten kan også sende Z-Wave pakker, men det er ikke ønske å legge dette i enheten da den vil gi potensiale for hacking av Z-Wave nettverk.

Tanken var å bygge videre på erfaringer jeg har fått fra bygging av denne enheten og en Sensor til Modbus USB enhet jeg lagde for en tid tilbake.

 

1 time siden, Moskus skrev:

Ikke for å punktere prosjektet ditt fullstendig, men er det egentlig behov for slikt? Hvordan har du tenkt å "formidle dataene til Z-wave"? Det er jo ikke akkurat som om det bare er å distribuere data som UDP.

Ved å bruke samme hardware som Z-Wave Snifferen er bygget på tenkte jeg å gjøre følgende:

I vanlig modus vil enheten gjøre følgende:

- Presentere seg som batteri drevet enhet for Z-Wave nettverket. Dermed trenger den ikke lytte på Z-Wave frekvensen konstant.

- Lytte etter enheter på 433 MHz.

- Ved jevne mellomrom flytte over til Z-Wave frekvensen å sende oppdateringer til kontroller.

 

USB enheten vil være selvstendig og det eneste den vil trenge er strøm. Den kan f.eks plugges inn i en mobillader. Firmware kan også oppdateres via USB.

Fordelen er at dette gjør det lettere på kontroller siden. For kontrolleren vil disse enhetene se ut som datapunkter under en vanlig Z-Wave enhet.

 

Mvh

Jon

  • Like 1
Lenke til kommentar
Del på andre sider

10 minutter siden, ZoRaC skrev:

Den største utfordringen jeg ser for meg er alle de forskjellige protokollene på 433 MHz. Man ser jo hvordan det ser ut i RFXCOM-plugin. Noen må jo utvikle/videreutvikle støtte for de forskjellige protokollene etter hvert. 

 

Ellers enig med @Moskus - man kan jo løse det med et eget interface og da er det jo likegyldig for systemet om det er 433 eller z-wave. 

Hei Zorac,

 

Veldig godt poeng. Det hadde vært interessant å høre hva slags enheter folk bruker på 433MHz idag. Jeg har støtte for å dekode Oregon1/2/3, wt450 og Nexa i tidligere enhet.

 

Mvh

Jon

Lenke til kommentar
Del på andre sider

13 minutter siden, Hr Kotelett skrev:

Drukket Yoda saften idag?

 

(Regner med du postet for tidlig ?)

 

 

Men en fordel jeg kan se om å få 433Mhz over på Z-wave kontra en egen kontroller er vel at da kan en få "lenger rekkevidde" på 433mhz produkter uten å bruke rpi+kontroller over nettverk, en annen sak er vel hvor mye trafikk det da vil bli på z wave nettverket da 433mhz produkter gjerne oppdaterer seg til faste intervaller uten muligheter for å justere det.

Hei Hr Kotelett,

 

Tidsintervalet 433 MHz sensoren bruker trenger ikke nødvendigvis påvirke Z-Wave nettverket. Det går ann å sette opp at de skal være synkrone eller at enheten kun sender på Z-Wave nettverket i et gitt tidsinterval.

 

Mvh

Jon

Lenke til kommentar
Del på andre sider

Jeg bruker fortsatt WS2500 fra ELV / Oregon Scientific. Og vil helst fortsette med det. Et problem er at det ikke er mottagere å få tak i lenger til disse. Sensorene dauer også etterhvert, men jeg har laget egne basert på samme RF protokoll i Atmel Studio / AVR. Men har ikke fått til å lage en mottager med god nok rekkevidde. Jeg har med SDR sett på hva som skjer på dette båndet og skjønner at det ikke er lett for mottakeren å skille hundelort fra fiken.

 

Er du interessert i RF protokollen til WS2500 så har jeg en meget god beskrivelse av den. Lager du en WS2500 til Z-Wave gateway så er jeg interessert. Det kan kanskje bli bedre enn en Z-Uno jeg har skaffet med tanke på dette. Jeg ser Qubino har laget en  gateway fra et sett værsensorer jeg mener å ha sett før hos CO eller Jula.

 

Og det er vel bare miljøsensorer som er interessant på denne frekvensen. Da er jo tap av enkelte overføringer ikke kritisk for funksjonen av hele systemet. Å sende en bønn om å skru av varmen uten mulighet for å sjekke om det faktisk skjedde er ikke holdbart.

Endret av Einar
Sleivskriving
Lenke til kommentar
Del på andre sider

Først må jeg si at det høres ut som et interessant prosjekt, og at grunnen til min skepsis kanskje kommer av at jeg enda ikke helt har forstått bruksområdet, eller kanskje snarere hvordan den skal fungere. ;) 

 

Men spennende er det! :) 

 

 

15 timer siden, suphammer skrev:

Jeg har laget en lavnivå Z-Wave stack som kjører inne i en liten USB Stick med en veldig fleksibel radio og en mikroprosessor uten bruk av Sigma Design sin egen Z-Wave radio.

Denne klarer idag å lytte til radio å presentere Z-Wave pakkene dekodet eller evt i råformat via serial port over USB uten bruk av ekstern software. Denne enheten kan også sende Z-Wave pakker, men det er ikke ønske å legge dette i enheten da den vil gi potensiale for hacking av Z-Wave nettverk.

Tanken var å bygge videre på erfaringer jeg har fått fra bygging av denne enheten og en Sensor til Modbus USB enhet jeg lagde for en tid tilbake.

Om du legger til en sender eller ikke er ikke det som for normale vil hindre hacking av Z-wave nettverk, så hvis det er en fordel så legg det til. De som har evnen til å hacke Z-wave vil kunne gjøre det uansett.

 

15 timer siden, suphammer skrev:

I vanlig modus vil enheten gjøre følgende:

- Presentere seg som batteri drevet enhet for Z-Wave nettverket. Dermed trenger den ikke lytte på Z-Wave frekvensen konstant.

- Lytte etter enheter på 433 MHz.

- Ved jevne mellomrom flytte over til Z-Wave frekvensen å sende oppdateringer til kontroller.

Det er de to siste punktene her som forsåvidt er utfordringen, slik jeg ser det. 

Som @ZoRaC sier, å "lytte til enheter på 433 MHz" er en utfordring med tanke på protokoller. Det er mange forskjellige her, men jeg tipper de mest brukte er Oregon sine og Viking-sensorer (som sikkert har en mer teknisk beskrivelse).

 

 

Å "sende oppdateringer til controller" er vel det jeg lurer på mest. Har du noen tanker her? Du har nok forståelse for Z-wave på et lavere nivå (dvs "bedre nivå") enn jeg har, men jeg lurer litt på hvordan denne USB-dingsen skal kunne oppdatere 20-30 temperatursensorer og hvordan disse blir presentert for controller...

 

 

Men hvis et slikt produkt finnes, ville det jo absolutt ha sine bruksområder. Samtidig kunne man jo også ønske seg evnen til å styre andre basic 433 MHz enheter, f.eks. Nexa-utstyr og Rollertrol-motorer. :) 

Lenke til kommentar
Del på andre sider

1 time siden, Einar skrev:

Jeg bruker fortsatt WS2500 fra ELV / Oregon Scientific. Og vil helst fortsette med det. Et problem er at det ikke er mottagere å få tak i lenger til disse. Sensorene dauer også etterhvert, men jeg har laget egne basert på samme RF protokoll i Atmel Studio / AVR. Men har ikke fått til å lage en mottager med god nok rekkevidde. Jeg har med SDR sett på hva som skjer på dette båndet og skjønner at det ikke er lett for mottakeren å skille hundelort fra fiken.

 

Er du interessert i RF protokollen til WS2500 så har jeg en meget god beskrivelse av den. Lager du en WS2500 til Z-Wave gateway så er jeg interessert. Det kan kanskje bli bedre enn en Z-Uno jeg har skaffet med tanke på dette. Jeg ser Qubino har laget en  gateway fra et sett værsensorer jeg mener å ha sett før hos CO eller Jula.

 

Og det er vel bare miljøsensorer som er interessant på denne frekvensen. Da er jo tap av enkelte overføringer ikke kritisk for funksjonen av hele systemet. Å sende en bønn om å skru av varmen uten mulighet for å sjekke om det faktisk skjedde er ikke holdbart.

Hei Einar,

 

Ser ikke bort fra muligheten til å implementere støtte for WS2500 på sikt. Men vil nok først og fremst konsentrere meg om et par protokoller som jeg har laget kode for før. Interesant at du har laget egene sensorer. Som du sier vil jo noe av utfordringen også være rekkevidde.

 

Hvordan fungerer identifiseringen på WS2500 ? Har hver sensor en unik id, setter man den med dip switcher eller blir det ny id hver gang batteri byttes ?

På Oregon kan enkelte sensorer ha 10 ID'er (Kanaler) i tillegg så genererer hver sensor en unik ID hver gang man bytter batteri. Med 10 ID'er har man jo en begrensning i antall sensorer...

Jeg har sett Qubino sin også, men den er som du nevner låst til spesifikk sensor.

 

Mvh

Jon

Lenke til kommentar
Del på andre sider

48 minutter siden, Moskus skrev:

Først må jeg si at det høres ut som et interessant prosjekt, og at grunnen til min skepsis kanskje kommer av at jeg enda ikke helt har forstått bruksområdet, eller kanskje snarere hvordan den skal fungere. ;) 

 

Men spennende er det! :) 

Deler av det er vel også interesse for å lære mere. Men det er en liten fordel at det kan brukes til noe også :)

48 minutter siden, Moskus skrev:

 

Om du legger til en sender eller ikke er ikke det som for normale vil hindre hacking av Z-wave nettverk, så hvis det er en fordel så legg det til. De som har evnen til å hacke Z-wave vil kunne gjøre det uansett.

Sant nok. Senderen er der, det er bare ikke laget noen CLI kommando å sende Z-Wave pakker. Det kan være greit med en slik kommando for debugging.

 

48 minutter siden, Moskus skrev:

Det er de to siste punktene her som forsåvidt er utfordringen, slik jeg ser det. 

Som @ZoRaC sier, å "lytte til enheter på 433 MHz" er en utfordring med tanke på protokoller. Det er mange forskjellige her, men jeg tipper de mest brukte er Oregon sine og Viking-sensorer (som sikkert har en mer teknisk beskrivelse).

 

 

Å "sende oppdateringer til controller" er vel det jeg lurer på mest. Har du noen tanker her? Du har nok forståelse for Z-wave på et lavere nivå (dvs "bedre nivå") enn jeg har, men jeg lurer litt på hvordan denne USB-dingsen skal kunne oppdatere 20-30 temperatursensorer og hvordan disse blir presentert for controller...

Tanken er først og fremst å bruke multi channel/instances. Utfordringen blir hvordan man skal identifisere de forskjellige sensorene i listen man får. En annen ting er hvordan de forskjellige kontrollerene håndterer at nye kanaler kommer etter inclusion. Det er ikke sikkert alle kontrollere kan legge til nye kanaler dynamisk. Så det gjenstår å teste.

Alternativt kunne man simulert flere Z-Wave noder, men tror det blir rotete. Spessielt med at man må holde oversikt over flere pairinger...

 

48 minutter siden, Moskus skrev:

 

Men hvis et slikt produkt finnes, ville det jo absolutt ha sine bruksområder. Samtidig kunne man jo også ønske seg evnen til å styre andre basic 433 MHz enheter, f.eks. Nexa-utstyr og Rollertrol-motorer. :) 

Har tenkt litt på dette også, men det vil ikke virke i den settingen jeg har tenkt. For den vil ikke være innom Z-Wave frekvensen ofte nok til at den kan respondere på disse kommandoene. Så da er man avhengig av å lage en egen enhet som virker omvendt. Dvs, lytter primært på Z-Wave og utfører kommandoer på 433MHz.

 

Mvh

Jon

Lenke til kommentar
Del på andre sider

Den 12.5.2017 klokken 21.24, suphammer skrev:

Hei,

 

Er litt inne på tanken rundt å lage en Z-Wave dongle som konverterer enkle sensorer som oregon (værsensor), Nexa komponenter etc til Z-Wave.

I praksis blir det en liten USB dongle som du putter i en USB strømforsyning. Den vil deretter formidle dataene fra disse sensorene til Z-Wave. Støtte for firmware oppgradering vil gjøre at man kan utvide med flere sensorer på sikt.

Er dette noe noen kunne tenke seg å se utviklet ?

Planen er å bygge videre på det jeg har gjort med Z-Wave Snifferen (https://www.suphammer.net/zwave_sniffer/).

 

Mvh

Jon

 

Qubino bruker en slik, "USB konverter stick", i lang tid: https://www.tronika.no/no/zwave-klimastyring/976-vaerstasjon-zmnhzd1.html

Lenke til kommentar
Del på andre sider

14 minutter siden, hkmod25 skrev:

Qubino bruker en slik, "USB konverter stick", i lang tid: https://www.tronika.no/no/zwave-klimastyring/976-vaerstasjon-zmnhzd1.html

Vi vet det... ;) 

 

3 timer siden, Einar skrev:

Jeg ser Qubino har laget en  gateway fra et sett værsensorer jeg mener å ha sett før hos CO eller Jula.

 

1 time siden, suphammer skrev:

Jeg har sett Qubino sin også, men den er som du nevner låst til spesifikk sensor.

 

Lenke til kommentar
Del på andre sider

@suphammer

Det er noen beskrivelser på nettet. Den absolutt beste er Helmuth Bayerlein: http://www.dc3yc.homepage.t-online.de/protocol.htm

Da jeg implementerte den i AVR fungerte det 100%. Mottkeren aksepterte det som sine egne sensorer.

ID er 3bit sensortype + 3bit sensoradresse. Den siste settes med jumpere i senderen. Med egne sensorer kan man også "juge litt" og presentere thermo/hygro som thermo/hygro/barometer.

 

Ellers er det en til her: http://www.osengr.org/WxShield/Downloads/Weather-Sensor-RF-Protocols.pdf

Den har jeg bare tittet gjennom, så kan ikke si om den er veiledende eller villedende.

 

Ellers bør du sette opp en RFLink om du vil sniffe litt. http://www.nemcon.nl/blog2/ Den er ikke veldig følsom, noe skyldes vel at den har litt grov oppløsning i pulsdetektoren. Den bruker busy wait for å lese pulser, ikke AVR's input capture funksjon.

 

En SDR dongle kan være kjekk for å se om problemet er at senderen ikke ligger på rett frekvens når mottager ikke fungerer som tenkt. Noen (C.O.) sensorer hos meg ligger langt fra på rett frekvens! Og da vil en forholdsvis smalbåndet mottager ikke levere gode signaler til MCU.

http://www.funcubedongle.com/MyImages/FCD2ManualV4.pdf

 

Bruker du samme chip for 433MHz og Z-Wave? Da vil vel ikke antennekretsløpet være riktig for begge bånd?

 

 

Lenke til kommentar
Del på andre sider

7 timer siden, Einar skrev:

@suphammer

Det er noen beskrivelser på nettet. Den absolutt beste er Helmuth Bayerlein: http://www.dc3yc.homepage.t-online.de/protocol.htm

Da jeg implementerte den i AVR fungerte det 100%. Mottkeren aksepterte det som sine egne sensorer.

ID er 3bit sensortype + 3bit sensoradresse. Den siste settes med jumpere i senderen. Med egne sensorer kan man også "juge litt" og presentere thermo/hygro som thermo/hygro/barometer.

 

Ellers er det en til her: http://www.osengr.org/WxShield/Downloads/Weather-Sensor-RF-Protocols.pdf

Den har jeg bare tittet gjennom, så kan ikke si om den er veiledende eller villedende.

 

Ellers bør du sette opp en RFLink om du vil sniffe litt. http://www.nemcon.nl/blog2/ Den er ikke veldig følsom, noe skyldes vel at den har litt grov oppløsning i pulsdetektoren. Den bruker busy wait for å lese pulser, ikke AVR's input capture funksjon.

Takk for linkene. Jeg har tatt en titt på RFLink og de har implementert mange protokoler, så det er definitivt en bra referanse.

 

7 timer siden, Einar skrev:

En SDR dongle kan være kjekk for å se om problemet er at senderen ikke ligger på rett frekvens når mottager ikke fungerer som tenkt. Noen (C.O.) sensorer hos meg ligger langt fra på rett frekvens! Og da vil en forholdsvis smalbåndet mottager ikke levere gode signaler til MCU.

http://www.funcubedongle.com/MyImages/FCD2ManualV4.pdf

Jeg har en SDR dongle selv. Nyttig når man feilsøker. Flere som har skrevet dekodere for forskjellige sensorer ved bruk av SDR også.

7 timer siden, Einar skrev:

Bruker du samme chip for 433MHz og Z-Wave? Da vil vel ikke antennekretsløpet være riktig for begge bånd?

 

 

Jeg bruker samme radio (http://www.ti.com/product/CC1101). Du har rett i at antennekretsløpet ikke vil være riktig for begge bånd, men jeg vil tro det allikevel vil bli bra nok signaler på 868MHz til at man kan sette den i nærhet av kontroller selv om man designer antennekretsløpet for 433MHz. Det viktigste er jo avstanden på 433MHz da sensorene er spredt.

 

Mvh

Jon

Lenke til kommentar
Del på andre sider

Balunen på referansedesignene er nok ganske smalbåndet. Men du kan jo legge inn en dual band splitter (diplexer) mellom CC1101 og 2 antenner?

Det ligger noen 433MHz cc1101 moduler i en skuff her. Jeg mener å huske de er ganske tett i øra utenfor båndet.

Kanskje det er verd et forsøk å fjerne Pi filteret mellom balun og antenne?

Eller kanskje en slik: https://www.johansontechnology.com/datasheets/chipset-specific/0433BM15A0001.pdf

 

Lenke til kommentar
Del på andre sider

22 timer siden, Einar skrev:

Balunen på referansedesignene er nok ganske smalbåndet. Men du kan jo legge inn en dual band splitter (diplexer) mellom CC1101 og 2 antenner?

Det ligger noen 433MHz cc1101 moduler i en skuff her. Jeg mener å huske de er ganske tett i øra utenfor båndet.

Kanskje det er verd et forsøk å fjerne Pi filteret mellom balun og antenne?

Eller kanskje en slik: https://www.johansontechnology.com/datasheets/chipset-specific/0433BM15A0001.pdf

 

Hei Einar,

 

Takk for mange bra tips. Virker som du virkelig er inne i dette her :) Å jobbe med radio design er ikke rett frem, så jeg har valgt i første om gang å bruke en ferdig modul.

Den får ganske bra signaler på både 433 MHz og 868 MHz for mottak av FSK (ved bruk av riktig antenne). Virker ikke som den følger referanse designet til TI. Jeg har begynt så vidt å flytte over noe kode jeg tidligere har skrevet. Så får vi se hvordan det går med OOK. Om det blir for mye støy med antenne designet i denne modulen.

 

Mvh

Jon

  • Like 1
Lenke til kommentar
Del på andre sider

Bli med i samtalen

Du kan publisere innhold nå og registrere deg senere. Hvis du har en konto, logg inn nå for å poste med kontoen din.

Gjest
Skriv svar til emnet...

×   Du har limt inn tekst med formatering.   Lim inn uten formatering i stedet

  Du kan kun bruke opp til 75 smilefjes.

×   Lenken din har blitt bygget inn på siden automatisk.   Vis som en ordinær lenke i stedet

×   Tidligere tekst har blitt gjenopprettet.   Tøm tekstverktøy

×   Du kan ikke lime inn bilder direkte. Last opp eller legg inn bilder fra URL.

×
×
  • Opprett ny...

Viktig informasjon

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