Svenska ElektronikForumet

Kom på nu när du säger det att du redan skickade batteri statusen.

Känns som att du redan har tänkt på allt så jag ska inte lägga mig i.

Utmärkt, fungerar fint

Har dock märkt två saker när jag prövade kopplingen:

När man börjar plugga fast sensorer av massor verkar det som om IDn börjar gå på varandra.
Vad jag kan räckna finns det "bara" 64 (16 * 4) och med min otur fick flere givare ID 111 och 121.
Men sedan fungerade många bra också och hittade ledia platser, bara att pröva sig fram.

Det andra är att Tellstick Net inte verkar reagera på denna fasten Tellstick Duo läser signalerna fint.
Har köpt några 36-1797 från Clas Ohlsson och de syns i både Duo och Net.

Projektet är helt fantasktiskt

Tack för de uppmuntrande orden

Jag förstår ditt problem med att sensorerna krockar. För mig har det dock aldrig hänt (har bara tillgång till 4 sensorer än så länge). Jag hade hoppats på att risken att det hände skulle vara mycket liten om jag använde de två minst signifikanta bytes:en i 1wire-adressen för att generera huskod respektive kanalkod. Jag tänker mig att det är de minst signifikanta bytes:en som förändras mest mellan varje komponent, men det kan vara ett felaktigt antagande.
Ett bättre sätt är nog att XOR:a ihop alla 6 bytes i 1wire-adressen och från den sedan generera huskod och kanalkod.
Jag ska se vad jag kan göra under kvällen ikväll.

Konstigt att den inte fungerar med Tellstick Net. Jag har mätt pulslängder och bit:ar, så det borde inte vara något problem med protokollet.
Kan det vara så att NET-modellen är buggig? Jag har ju läst på Telldus Forum att det är många som gått tillbaka till butiken med sina ESIC-termometrar för att de varit "trasiga". Eller finns det kanske en fördröjning mellan att sändaren slås på tills att den dyker upp i Live?

Jag kan ju ärligt säga att jag inte äger en NET, utan tog för givet att jag implementerat Mandolyn-protokollet rätt så att den därför skulle fungera öven för dom som har Telldus NET.

Jag ska försöka lägga in XOR:en ikväll.

Ytterligare planer för kommande releaser:
När jag fått hem mina fuktighetssensorer DHT22 så tänkte jag även implementera stöd för den. Det innebär troligen att även DHT11 kommer att stödjas.
Ytterligare något som ligger i röret är att lägga till stöd för DS2423b (1wire-räknare) så att man trådlöst kan övervaka elförbrukningen ... men nu ska jag inte lova för mycket

Finns det andra (realistiska) önskemål?

Petade lite idag och programmerade din esic clone v1 i en pic.
Den raporterade både temperatur och "fuktighet", samt dök upp efter ca 5 min i Telldus Live.

Tänkte först det vad sändarmodulen jag använde, eftersom den är stulen ur en Clas Ohlson 36-4744
Köpte några för att lista ut protokollet men fick sönder en av dem, men ingen fara då jag får användning av skalet och sändaren till detta projekt

Tror problemet mer ligger i att "fuktigheten" är 0, att det är det som är orsaken till att Tellstick Net inte gillar sändningen.
Esic clone v3 skickar "fuktighet" så Tellstick Duo ser den som 0, medan esic clone v1 sändning mottogs som 88, tror detta kan vara orsaken.

pi@raspberrypi ~ $ tdtool -l
SENSORS:
PROTOCOL MODEL ID TEMP HUMIDITY LAST UPDATED
mandolyn temperaturehumidity 104 25.5° 0% 2013-02-05 18:20:04
mandolyn temperaturehumidity 102 25.5° 0% 2013-02-05 18:19:43
mandolyn temperaturehumidity 73 25.7° 0% 2013-02-05 18:19:44
mandolyn temperaturehumidity 152 25.5° 0% 2013-02-05 18:19:44
mandolyn temperaturehumidity 121 25.4° 0% 2013-02-05 18:20:04
mandolyn temperaturehumidity 1 25.5° 0% 2013-02-05 18:20:03
mandolyn temperaturehumidity 111 3.2° 0% 2013-02-05 18:20:03
mandolyn temperaturehumidity 41 3.2° 0% 2013-02-05 18:20:02
mandolyn temperaturehumidity 83 25.6° 0% 2013-02-05 18:20:03
pi@raspberrypi ~ $

Kopplade finns 7st DS18B20, 1st DS1822 och 2st DS1820 (samma som DS18S20).
På ID 121 finns både en DS18B20 och DS1822, det att de är olika serier kan säkert bidra till att de enklare får samma ID.
På ID 41 och 111 ser ni klart var DS1820 finns, temperaturen avläses felaktigt.
Orsaken till detta är att DS1820 är 9-bit medan DS18B20 och DS1822 klarar 9-12-bit.
Det går enkelt i koden att ändra avläsningen till 9-bit så alla fungerar fint, men då går man miste om den extra nogrannheten de extra bittarna ger.
Så undvik helt enkelt DS1820/DS18S20.

Hade mer tur när jag på tur plockade givare för detta test, då bara två fick samma ID, skall experimentera lite till och se hur det går

Konstigt att version 3 inte visar batteristatus. Den implementationen är inte förändrad mellan versionerna.
Inte heller koden relaterad till sändningen av batteristatus.
Har du dubbelkollat din elektriska koppling?
Jag har också svårt att tro att det är pga att den visar 0% som den inte visas i Live, men konstigare saker har ju hänt
Om du vill testa din tes så kan du ju enkelt gå in i version 3 och hårdkoda värdet 50 och se om de dyker upp då.

Apropå elektrisk koppling. Version 3 stödjer inte parasitkopplade sensorer. Jag fick inte det att fungera något vidare så jag gav upp det för nu. Man kan alltså inte bara byta mjukvaran från version 1 till 3 utan att ändra den elektriska kopplingen till 1-wire-sensorerna.

Jag tror du har mycket rätt i att DS18S20 inte ger rätt temperatur. Den har ett annat format på temperatur-byte:n som skickas. Det blir ingen åtgärd i nästa version angående det. Kanske senare.

Om jag hinner så ska jag publicera version 0.4 ikväll där jag lägger till XOR:ad 1wire-serienummer som huskod och kanalkod.

esic_clone-0.4 finns att ladda ner.

Fantastiskt!
Följer projektet med stor spänning.

Kollade på RawEvent funktionen men hade hoppats på mer information, utskrift som hex etc etc
Fick inte Phyton scriptet att fungera så Raspbian så var tvungen att använda funktionen som finns för C.

Har en Esic termometer köpt från Clas Ohlsson (ID 111) som visar data exakt lika som Esic clone v4 (ID 124).
Verkar bara vara att Tellstick Net är mycket mer småpetig eftersom denna inte tar emot signalerna fast Tellstick Duo gör det.
Net blinkar inte ens till, det gjorde den med Esic clone v1 då det fungerade ända till Telldus Live.

Batteristatus syns nu, men verkar vara nåt konstit där.
Som 70% kommer temperaturen korrekt, som 69% blir det fel vid andra avälsningen.
Detta återproducerat med strömkälla och variabelt motstånd.

Eftersom jag verkar ha en massa konstiga problem, misstänker jag att jag skadat nån komponen så kollar saken igen bara jag får de nya jag beställt.

Om jag med ett oscilloskop kollar signalen som går till sändaren och jämför clone v1 med clone v3/v4, borde inte det vara enklaste sättet att verifiera om sändningen ser lika ut och på det sättet försöka finna vad Net inte gillar?

Skumma fel du får.

Eftersom du använder en annan transmitter, så skulle det kunna vara så att den behöver en längre starttid än den jag använder.
Det är i alla fall något som skiljer sig mellan de olika versionerna, hur lång tid innan sändning, som jag slår på spänningen till TX-modulen.

Du skulle kunna prova med att koppla in TX-modulen konstant till Vcc och GND och se om det gör någon skillnad.

Du råkar inte ha en DHT22 hemma? Jag håller på att implementera stöd för den och är snart färdig. Tyvärr är det svårt att testa koden eftersom jag inte har fått hem den jag beställt än.

Hur var det förresten med DS1822, fungerar den sensorn som förväntat? Kan vara bra att veta vilka sensorer min kod har stöd för

En annan sak. Har du fortfarande id-krockar med version 0.4 där jag xor:ar hela serienummret?

Ja, misstänker det kan vara PIC chippet som kanske skadats i testerna.

Har beställt några olika sändare men posten från Kina är aningen långsam, känns som evigheter då man väntar på nånting man behöver
(DealExtreme har sändare för ca $2/st)

Har experimenterat med regulerad strömkälla och på 3,3V är det ingen skillnad om sändaren är kopplad direkt eller via transistor.
På 5V har jag inte vågat koppla sändaren konstant eftersom jag inte är säker på att den klarar det, finns inte mycket data om sändaren jag använder.

På beställningen finns några DHT22 men ligger fortfarande nånstans på posten.

DS18B20 och DS1822 fungerar, de stöder båda 12-bit så avläses lika.
Skillnaden mellan dessa är att DS1822 är lite billigare och har 2,0 graders noggranhet där den lite dyrare DS18B20 har 0,5 graders noggranhet.

Händer nog fortfarande att IDn krockar med varandra men tror det bara är att inse att de gör det och tror inte det går enkelt att korrigera, med tanke på hur lite möjligheter det finns med de bitar som finns tillgängliga för ID.
Har 10 sensorer kopplade, av maximalt 64 möjliga IDn är det då redan 15%, så om man beaktar murphy och gör sannolikhetskalkyl etc tycker jag det är rätt bra att det sker bara en ID kollision
Samma resultat med båda systemen att räkna ut ID.

Bästa lösningen på ID problemet är att köpa många givare och välja ut de som får unika IDn till detta projekt och använda rästen till nåt annat

Man skulle kunna lagra id:t på sensorerna i picen och sedan skicka dem efter varandra i samma ordning med stegrande id.
Antar att id ändå sparas i picen för att kunna fråga sensorerna efter data eller körs en sökning varje gång?

Posten från Kina är olidligt långsam

Jag gissar att du kommer att få lite bättre sändningskvalite med sändarna från DX.

I just ditt fall med krockande device, så borde det hjälpa att jag även inkluderar device-typ också, i framtagandet av huskod och kanalkod. För var det inte så att det var en DS18B20 och en DS1822 som krockade?
Jag kan lägga in det i nästa release om du vill.

I v4 var det två DS18B20 som krockade men i v3 en DS18B20 och en DS1822.

Funderade att pröva på att i koden stänga av att den skickar samma sak flere gånger efter varandra.
Dvs att den bara skickar varje sensor en gång.
Är det nåt jag enkelt kan göra i koden för att göra det?

Tänkte med oskiloskopet kolla om jag skulle finna vad det är Net inte tycker om.
Kolla hurdan signal sändaren får och vad mottagaren ser.
Men mycket möjligt att det är sändaren.

Leta efter en rad med variabeln "PacketCounter".
I raden ovanför ska det stå "movlw .3". Ändra den till "movlw .1". Då skickas bara ett paket för varje sensor.

Prövade att använda mig av en logikanalysator, är en tid sedan senast så kunskaperna har rostat lite
Lade den att vänta på att PICen stänger av strömmen till led och 1-wire och genast efter börja logga data-pinnen till sändaren.

Verkar som om pulserna är olika långa på v1 och v4.
Men kan nog inte tyda vad den skickat, får inte det att stämma med specifikationen för protokollet.
Dock ser Duon denna data rätt så det är fel i mig och inte i sändningen