Trådlös 433 MHz temperatursensor för Tellstick och RFXtrx433

[ecenier]

Du har ett PM.

/N

[Pixi]

Halloj

Det funkar bättre men den beter sig fortfarande lite skumt.

satte först i en pic med esic clone för att verfiera att allt är som det skulle med min pir, och detta funkar pesis som det är tänkt.

men med fineoffset så ser det ut så här:

andreas@debian:~$ php telldusevet.php | grep "id:154"
16:TDRawDeviceEvent68:class:sensor;protocol:fineoffset;id:154;model:temperature;temp:23.7;i-1s13:TDSensorEvent10:fineoffset11:temperaturei154si1s4:23.7i1379018796s
16:TDRawDeviceEvent68:class:sensor;protocol:fineoffset;id:154;model:temperature;temp:23.7;i-1s13:TDSensorEvent10:fineoffset11:temperaturei154si1s4:23.7i1379018796s
16:TDRawDeviceEvent68:class:sensor;protocol:fineoffset;id:154;model:temperature;temp:23.7;i-1s13:TDSensorEvent10:fineoffset11:temperaturei154si1s4:23.7i1379018797s
16:TDRawDeviceEvent68:class:sensor;protocol:fineoffset;id:154;model:temperature;temp:23.7;i-1s13:TDSensorEvent10:fineoffset11:temperaturei154si1s4:23.7i1379018797s
16:TDRawDeviceEvent68:class:sensor;protocol:fineoffset;id:154;model:temperature;temp:23.7;i-1s13:TDSensorEvent10:fineoffset11:temperaturei154si1s4:23.7i1379018797s
16:TDRawDeviceEvent68:class:sensor;protocol:fineoffset;id:154;model:temperature;temp:23.7;i-1s13:TDSensorEvent10:fineoffset11:temperaturei154si1s4:23.7i1379018797s
16:TDRawDeviceEvent68:class:sensor;protocol:fineoffset;id:154;model:temperature;temp:23.7;i-1s13:TDSensorEvent10:fineoffset11:temperaturei154si1s4:23.7i1379018798s
16:TDRawDeviceEvent68:class:sensor;protocol:fineoffset;id:154;model:temperature;temp:23.7;i-1s13:TDSensorEvent10:fineoffset11:temperaturei154si1s4:23.7i1379018798s
16:TDRawDeviceEvent68:class:sensor;protocol:fineoffset;id:154;model:temperature;temp:23.7;i-1s13:TDSensorEvent10:fineoffset11:temperaturei154si1s4:23.7i1379018877s
16:TDRawDeviceEvent68:class:sensor;protocol:fineoffset;id:154;model:temperature;temp:23.7;i-1s13:TDSensorEvent10:fineoffset11:temperaturei154si1s4:23.7i1379018878s
16:TDRawDeviceEvent68:class:sensor;protocol:fineoffset;id:154;model:temperature;temp:23.7;i-1s13:TDSensorEvent10:fineoffset11:temperaturei154si1s4:23.7i1379018878s
16:TDRawDeviceEvent68:class:sensor;protocol:fineoffset;id:154;model:temperature;temp:23.7;i-1s13:TDSensorEvent10:fineoffset11:temperaturei154si1s4:23.7i1379018878s
16:TDRawDeviceEvent68:class:sensor;protocol:fineoffset;id:154;model:temperature;temp:23.7;i-1s13:TDSensorEvent10:fineoffset11:temperaturei154si1s4:23.7i1379018878s
16:TDRawDeviceEvent68:class:sensor;protocol:fineoffset;id:154;model:temperature;temp:23.7;i-1s13:TDSensorEvent10:fineoffset11:temperaturei154si1s4:23.7i1379018879s
16:TDRawDeviceEvent68:class:sensor;protocol:fineoffset;id:154;model:temperature;temp:23.7;i-1s13:TDSensorEvent10:fineoffset11:temperaturei154si1s4:23.7i1379018879s
16:TDRawDeviceEvent68:class:sensor;protocol:fineoffset;id:154;model:temperature;temp:23.7;i-1s13:TDSensorEvent10:fineoffset11:temperaturei154si1s4:23.7i1379018879s
16:TDRawDeviceEvent68:class:sensor;protocol:fineoffset;id:154;model:temperature;temp:23.7;i-1s13:TDSensorEvent10:fineoffset11:temperaturei154si1s4:23.7i1379018879s
16:TDRawDeviceEvent68:class:sensor;protocol:fineoffset;id:154;model:temperature;temp:23.7;i-1s13:TDSensorEvent10:fineoffset11:temperaturei154si1s4:23.7i1379018879s
16:TDRawDeviceEvent68:class:sensor;protocol:fineoffset;id:154;model:temperature;temp:23.7;i-1s13:TDSensorEvent10:fineoffset11:temperaturei154si1s4:23.7i1379018879s
16:TDRawDeviceEvent68:class:sensor;protocol:fineoffset;id:154;model:temperature;temp:23.7;i-1s13:TDSensorEvent10:fineoffset11:temperaturei154si1s4:23.7i1379018880s
16:TDRawDeviceEvent68:class:sensor;protocol:fineoffset;id:154;model:temperature;temp:23.7;i-1s13:TDSensorEvent10:fineoffset11:temperaturei154si1s4:23.7i1379018880s

andreas@debian:~$ tdtool -l
Number of devices: 0
SENSORS:

PROTOCOL MODEL ID TEMP HUMIDITY LAST UPDATED
fineoffset temperature 255 -204.7° 2013-09-12 22:48:47
fineoffset temperature 135 -21.0° 2013-09-12 22:48:18
fineoffset temperature 203 -21.0° 2013-09-12 22:48:28
fineoffset temperaturehumidity 142 23.7° 57% 2013-09-12 22:49:06
fineoffset temperaturehumidity 208 -204.4° 15% 2013-09-12 13:24:26
fineoffset temperature 154 23.7° 2013-09-12 22:49:05


Detta kom in när den låg helt isolerad i ett skåp.

Helst av allt skulle jag villa få esic clone att funka som det skall med rfxtrx, men rfx klagar på paketet som skickas ut

Detta kommer i rfxmanager:

Kod: Markera allt

08030302208F664987
Packettype        = UNDECODED RF Message
UNDECODED HIDEKI:208F664987
------------------------------------------------
08030302208F663994
Packettype        = UNDECODED RF Message
UNDECODED HIDEKI:208F663994
------------------------------------------------
08030302208F6639A7
Packettype        = UNDECODED RF Message
UNDECODED HIDEKI:208F6639A7

så här ser ett godkänt paket ut från esic (orginal classe sensor)

Kod: Markera allt

Received                = 0A 52 08 00 01 01 00 EE 1C 02 69
Date/Time              = 2013-04-25 15:50:00
Packet Length        = 0A
Packettype             = Temperature and humidity sensors
Subtype                  = WT260,WT260H,WT440H,WT450,WT450H
Seqnbr                   = 00
Id                            = 0101
Temperature          = 23.8 C
Humidity                 = 28
Humidity Status      = Normal
Battery                    = 9
Signal level              = 6

Sebastion Sjöholm (rfxcmd) har kollat lite och har även mailat RFXcom och det verkar vara lite problem med checksum biten
RFXtrx433 kollar denna och om den inte är ok så blir meddelandet inte ok, kan ju vara så att telldus är lite mer förlåtande eller ??

On Apr 26, 2013, at 05:37 , Sebastian Sjoholm <sebastian.sjoholm@gmail.com> wrote:

Jag kolla på hans kod för pic;

; Packet content for the Mandolyn protocol
;
; - 4-bit preamble
; - 4-bit House Code (Here, 6 byte 1-wire id XOR:ed is used)
; - 2-bit Channel Code (Here, 6 byte 1-wire id XOR:ed is used)
; - 2-bit Unknown (always b'11')
; - 1-bit Battery status (here always b'0')
; - 7-bit Humidity (here it represents battery status)
; - 12-bit Temperature from 1-wire sensors
; - 2-bit packet sequence number (0-2)
; - 2-bit Checksum

Och jämförde med sidan här:

http://ala-paavola.fi/jaakko/doku.php?id=wt450h

b00 - b03 (4 bits): Constant, 1100, probably preamble
b04 - b07 (4 bits): House code (here: 0001 = HC 1)
b08 - b09 (2 bits): Channel code - 1 (here 00 = CC 1)
b10 - b12 (3 bits): Constant, 110
b13 - b19 (7 bits): Relative humidity (here 0111011 = 59 %)
b20 - b34 (15 bits): Temperature (see below)
b35 - b35 (1 bit) : Parity (xor of all bits should give 0)

Det verkar som han hanterar "parity" lite annorlunda, den är 2 bitar istället för 1 bit.

MVH Sebastian

Något du kan kolla på ??

/Andreas H

[ecenier]

Min ESIC gick sönder av någon outgrundlig anledning när jag skulle löda på kablar för att mäta pulståget ut från sändaren

Det verkar vara slut i hela stockholm och i webbutiken hos Clas Ohlson. Finns den att köpa på något annat ställe?
Jag har ju iofs inte så jättestor lust att köpa en ny då jag har sensorer så jag klarar mig nu när jag har mina egna

En kommentar på det där med checksummebiten/bitarna.
Den tolkning av protokollet som du länkat till är jag lite fundersam till om det stämmer. Den sensor som skickar enligt den tolkningen, fungerar den med RFXCom?
Jag har två anledningar till varför jag tror att mitt protokoll är hyfsat rätt (men inte riktigt ändå eftersom det inte fungerar på RFXCom )
1. I min tolkning så används två bitar till att ange vilket paket i ordningen som skickas i paketskuren. Det är 1,2,3. Varje gång. Detta om man mäter på en ESIC. Att det skulle slumpat sig så de gånger jag tittat (~20ggr) känns lite osannolikt. Tittar man dessutom på tiondelen på temperaturen som skickas från ESIC och presenteras av telldus, så kan man t.ex. se paket1:24.5C, paket2:24.5C, paket3:24.6C.
Notera det sista paketet. Där blir helt plötsligt temperaturen en tiondel mer. Detta är jag ganska säker på beror på att telldus tolkar in paketordningsbitarna som en del av temperaturen istället.

2. Jag läste på något forum en tolkning av mandolyn-protokollet där de två sista bitarna var xor av jämna respektive udda bit:ar (typ. Minns inte detaljerna och orkar inte titta i koden nu). När jag tittade på det data som skickades från ESIC-sensorn så stämde detta varje gång. Detta kändes också för osannolikt att inte vara sant.

Faktum kvarstår att min tolkning av mandolyn inte fungerar på RFXCom av någon anledning. Jag tror att det beror på något annat än checksumman, men det kan bara spekulera i så länge man inte kan läsa källkoden för hur RFXCom tolkar protokollet. Kan man läsa källkoden? Är den öppen?

Skulle det kunna vara så att de filtrerar bort paketen från esic_clone om t.ex. humidity-fältet inte faller inom 0-100%? Så gör ju telldus i fineoffset-protokollet.

EDIT: Lägger till scriptet som visar vad jag menar med att tiondelen på temperaturen varierar vid flera tillfällen i en paketburst från ESIC WT450H.

callbacks.py.txt

[Pixi]

Behöver jag säga mer

------------------------------------------------
Received = 0A 52 08 00 09 03 80 B4 4B 03 89
Date/Time = 2013-09-18 20:01:28
Packet Length = 0A
Packettype = Temperature and humidity sensors
Subtype = WT260,WT260H,WT440H,WT450,WT450H
Seqnbr = 00
Id = 0903
Temperature = -18.0 C
Humidity = 75
Humidity Status = Wet
Battery = 9
Signal level = 8



------------------------------------------------
Received = 0A 52 08 00 08 04 02 29 4A 03 89
Date/Time = 2013-09-18 20:01:31
Packet Length = 0A
Packettype = Temperature and humidity sensors
Subtype = WT260,WT260H,WT440H,WT450,WT450H
Seqnbr = 00
Id = 0804
Temperature = 55.3 C
Humidity = 74
Humidity Status = Wet
Battery = 9
Signal level = 8


Än så länge funkar det som det skall

Skall bara lägga kidsen sen så skall här testas mer:-)

MVH en glad Andreas

[ecenier]

Toppen Pixi! Tack för verifieringen.

Jag har nu lagt upp en ny version av esic_clone av båda grenarna.

Checksumman räknades alltså ut korrekt, men det var initialvärdet som var fel.
Min tolkning av protokollet stämmer än

[Pixi]

Halloj igen

nu har jag kört hela natten och allt går fint om ,men ibland när jag triggar "pir" så verkar det slumpvisa värdet gå ut med det nästkomande vanliga id nummret
gäller både tellstick och rfxtrx
efter det så trippar det på som vanligt igen ??

sen har jag sett att ibland så blinkar den för vanlig sändning med det kommer inte in något i loggen ??

någon ide ???

tellstick:

Kod: Markera allt

mandolyn            	temperaturehumidity 	84   	38.7°	25%     	2013-09-19 23:19:10 
mandolyn            	temperaturehumidity 	93   	-34.0°	31%     	2013-09-19 23:19:06 

rfx

Kod: Markera allt

0A520802090381541F0249
Packettype    = TEMP_HUM
subtype       = TH8 - WT260,WT260H,WT440H,WT450,WT450H
                channel 3
Sequence nbr  = 2
ID            = 2307
Temperature   = -34 °C
Humidity      = 31
Status        = Normal
Signal level  = 4
Battery       = OK
------------------------------------------------
0A52080208040183190259
Packettype    = TEMP_HUM
subtype       = TH8 - WT260,WT260H,WT440H,WT450,WT450H
                channel 4
Sequence nbr  = 2
ID            = 2052
Temperature   = 38,7 °C
Humidity      = 25
Status        = Normal
Signal level  = 5
Battery       = OK
------------------------------------------------

Andreas H

[ecenier]

Det första problemet känner jag till, men jag tycker inte att det gör så mycket.
Jag ska se om jag kan åtgärda det i ett kommande släpp. Det handlar om att spara undan även tempen vid ett interrupt så att den går att återställa efter interruptet.

Den andra frågan är ju väldigt svår att svara på utan att mäta på sändaren vid det tillfället som det inte verkade komma fram. En gissning är att paketen störs ut av något.
Jag tvivlar på att det är picen eller transmittern som hickar till. Än mindre min kod förstås
Hur har du förresten sett det? Vet du hur förekommande det är?

[Pixi]

Halloj igen

Det som ställer till det med problem 1 är att jag loggar till en rrd databas och utifrån den så skapar jag grafer , dessa grafer kommer få väldigt knepiga kurvor om man säger så

MVH
Andreas H

[ecenier]

Har en rättning om du vill prova.

[Pixi]

Gärna
Förste testare

[sonnyboy]

Vad händer om man har en ds18b20 kopplad och sedan bryts gnd, vad levererar clonen för värde då? Är inte hemma och kan pröva. Fick en fin fin idé att sätta tempgivare på råttfällorna på vinden som övervakas av clonen. Då slipper man kolla dom stup i kvarten. Har en liknande lösning på 1-wire och den levererar error när kontakten bryts och då skickas ett mail och ett sms.

[ecenier]

Tyvärr kommer nog ingenting att hända eftersom ingen presence-signal kommer att komma. Enklaste är att använda pir-ingången, men då kan du bara ha en fälla per sändare.

[ecenier]

esic_clone-0.9.2 finns att ladda ner från första posten.

[ecenier]

esic_clone-0.9.3 samt fineoffset_clone-0.5 finns att ladda ner från första posten.

[sebastianand]

Fantastiskt projekt!

Satte själv ihop både en ver version<=0.6 och en version>=0.7 igår. Fungerade perfekt, dock så fick jag ändra humidity/(batteri) värdet under 100 för att domoticz klagade på invalid value och visade inte sändren/sensorn om det var över 100....

En fråga, är det möjligt att strunta i DS18B20 om det räcker med tempsensorn i dht'n, snurrar inte igång för mig när jag prövar det...

En till fråga, Är det någon som lyckats få in en pulsmätare så man kan mäta elförbrukningen? Någon som har koll på ett fungerande protokoll till det?

Mvh Sebastian