Instabilt OWFS

[zingo]

Jag kör sedan flera år en Ubuntu-server med en 1-wireslinga på kanske 50 m med ett antal tempsensorer, räknare för elmätaren, ljussensorer mm som i stort sett funkat bra och stabilt.

I servern har jag ett antal php-script som körs av cron då och då, oftast varje minut, och som läser av olika sensorer och gör olika saker beroende på det avläsa värdet.
I början lät jag alla scripten läsa av värdena direkt i owfs-filstrukturen men efter en stund hängde sig nätet och det slutade funka. Om jag startade om owfs-programmet så funkar det igen. Jag provade med att istället låta ett cronscript kopiera över alla sensorernas värden varje minut i en annan katalogstruktur med samma namn och sen lät jag alla scripten läsa från kopian istället och då blev det stabilt. Jag vet inte om problemen berodde på kollisioner eller så men det funkade. Alla script, utom kopieringsscriptet, väntar tio sek efter starten innan de läser för att undvika att de läser under kopieringen eftersom alla script körs från cron och därför startas samtidigt.

Nu håller jag på o labbar med en ny server som just nu har ett par sensorer och en LCD-display och har en DS9490R för att driva den lilla slingan på några dm.
I bakgrunden har jag Domoticz som läser av en av tempsensorerna och det kan gå stabilt i mer än ett dygn. Om jag nu via ett script skriver i displayen så går det några gånger men sen hänger sig owfs på samma sätt som tidigare. Om jag stoppar owfs, demonterar /mnt/1wire-katalogen och startar om owfs så funkar det igen. Det spelar ingen roll om jag har ett bash-script eller kör php för att skriva i displayen, det blir samma sak efter en stund ändå. Så får allt vara i fred funkar det men skriver jag till displayen så slutar det att funka efter några skrivningar.

När det blivit fel så visas bara några katalograder i /mnt/1wire/ (bus.0, settings, statistics mm) men efter att jag startar om owfs så dyker även sensorerna upp igen.

Är det någon annan som har liknande problem eller som har en lösning på problemet eller förslag på felsökning?

LCD-interfacet och sensorerna är de som finns på m.nu och bortsett från att owfs verkar lite känsligt så funkar det bra.

/Christer

[elf98]

Kör du senaste versionen av OWFS?
Testa att sätt en USB-hubb mellan dator och USB- adapter.

[flyvert]

Jag har i flera år kört en lösning som liknar din, dvs skript (mer än ett), 1-wire och LCD.
Skillnaden är att jag kör med I2C-baserad busmaster (m.nu:s), faktiskt två stycken och (två) Raspberry Pi (1 x owserver + 1 x owfs).

Min erfarenhet av OWFS är att när man väl fått igång den (har provat både apt-get och egenkompilerad, kör den senare sen ett par år) så går den bra. Har tvingats starta om den några gånger under åren, men jag tror att jag kommit på att ett "find" kommando som snabbt läser alla filer kan lösa ut någon bugg, etc. Är man hemma på skript kan man sätta en "wrapper" som bara väntar på att OWFS kraschar och därefter startar en ny.

Känner inte att LCD är ett problem, började skriva 1 ggr/minut för att nu ha en asynkron lösning där ett nytt givarvärde driver uppdatering. Nu skulle jag tro att jag skriver kanske uppemot 10 ggr per minut till min LCD utan några som helst stabilitetsproblem med OWFS.

Förslag på felsökning:
1. Minimera nätet till LCD, 1 sensor och 0.5 meter kabel. Bygg sedan ut nätet tills problemen kommer
2. Om du kör med en apt-get version av OWFS, läs på vad senare källkodsversioner innebär för rättningar o kompilera själv. Kanske finns en buggrättning? Har du väl kompilerat en egen version och problemen fortsätter kan du kompilera om med debug och köra owfs i debuggern och få den att krascha och visa var det smäller. En utvecklare av OWFS (finns på forum) kan sen kanske hjälpa dig om du inte själv kan koda.
3. Slå på debugutskrifter (http://owfs.org/index.php?page=debugging) och försök se vad som sker

[zingo]

Min erfarenhet av OWFS är att när man väl fått igång den (har provat både apt-get och egenkompilerad, kör den senare sen ett par år) så går den bra. Har tvingats starta om den några gånger under åren, men jag tror att jag kommit på att ett "find" kommando som snabbt läser alla filer kan lösa ut någon bugg, etc. Är man hemma på skript kan man sätta en "wrapper" som bara väntar på att OWFS kraschar och därefter startar en ny.

Känner inte att LCD är ett problem, började skriva 1 ggr/minut för att nu ha en asynkron lösning där ett nytt givarvärde driver uppdatering. Nu skulle jag tro att jag skriver kanske uppemot 10 ggr per minut till min LCD utan några som helst stabilitetsproblem med OWFS.

Förslag på felsökning:
1. Minimera nätet till LCD, 1 sensor och 0.5 meter kabel. Bygg sedan ut nätet tills problemen kommer
2. Om du kör med en apt-get version av OWFS, läs på vad senare källkodsversioner innebär för rättningar o kompilera själv. Kanske finns en buggrättning? Har du väl kompilerat en egen version och problemen fortsätter kan du kompilera om med debug och köra owfs i debuggern och få den att krascha och visa var det smäller. En utvecklare av OWFS (finns på forum) kan sen kanske hjälpa dig om du inte själv kan koda.
3. Slå på debugutskrifter (http://owfs.org/index.php?page=debugging) och försök se vad som sker

Ok, tack för dina förslag!

Stabiliteten du beskriver stämmer ungefär med det jag nu har i det "gamla" systemet som gått flera år med nån omstart då och då. Men som du skriver så finns det sätt att få det att kantra också

Jag har i andra sammanhang just en sån lösning som startar om saker som går på näsan men just med OWFS är det lite annorlunda eftersom den inte verkar stanna helt utan det är "bara" sensorerna som försvinner. Och när jag försöker komma åt en sensor så tar det kanske runt 30 sek som den hänger innan man får ett svar. Iofs har jag ett skript som jag kör manuellt för att starta om OWFS när det händer och den skulle jag ju kunna köra automatiskt. Men det vore roligare om jag fick den nya lika stabil som jag till slut fått den gamla installationen, den som styr belysning i huset, mäter elförbrukning, väder mm och bl.a levererar till temperatur.nu

Just nu är det nya nätet som jag håller på o meckar med så litet som du beskriver, det är ett par tempsensorer och displayen och ett par dm sladd och det går ganska stabilt så länge det bara får "sköta sig själv". Har kört det ett par dygn utan problem så länge jag inte skriver till displayen, då har det ofta strulat efter ett tag, dock inte direkt utan det kan gå några gånger innan det krånglar. Först hade jag dongeln på en strömförsörjd hub men jag provade med att flytta den till datorn för att eliminera hubben som kanske kan krångla.

Jag kompilerade först OWFS från källkod men när det inte funkade så bra så installerade jag från paket istället men jag är inte säker på att det blev någon avsevärd skillnad just av det men efter en del meckande och omstarter mm tror jag nu att jag fått det lite stabilare med displayen.
Dock har nu istället mottagningen av en temp- och fuktsensor via RFXtrx slutat funka istället
Jag tänkte se om Domoticz kan vara till någon nytta för att slippa ifrån en del kodande så jag låter den ta emot meddelanden via USB från mottagaren (OWFS är inte aktiverat i Domoticz för att inte störa experimenten) och det har funkat bra under veckan men nu har det lagt av istället.

RFXtrx är det andra problemområdet som jag har som inte heller vill sig. Den kan ibland kännas väldigt okänslig för signaler och en del av protokollen som jag behöver kolliderar med varandra så jag måste välja det ena. Men nu när jag har ett testsystem tänkte jag försöka få liv i den också. I den gamla installationen har jag en Tellstick för att styra lampor mm med o den funkar bra.

Jag ska kolla enligt dina förslag o se om jag kan hitta nåt som sprider ljus över problemet.
Tack för tipsen!
/c

[flyvert]

Har själv sporadiska problem med en RFXTrx433 (inte den nya E-varianten) och fick lägga ned försöken att styra lite UPM-relän som jag fick av en kompis som inte längre behövde dem. Har en handfull 433 MHz givare som oftast, men inte alltid fungerar. Tror att den externa GP-antennen hjälper något med räckvidden, men att det är något som periodvis stör ut mottagningen för en av mina givare. Alla givare och mina grannar delar ju på frekvensen så det är väl inte omöjligt att någon av givarna hamnar "i fas" med en annan o de släcker ut varandras sändningar. Vidare verkar man inte köra med någon paritet eller checksumma, har någon enstaka gång fått +50 grader från en givare som ligger i en frys... Du känner väl till RFX-toolen som du konfar och kör in ny firmware, etc med? Tror faktiskt att man med ett terminalemulatorprogram (t.ex. minicom) och genom att öppna "/dev/ttyUSB0" mot burken får se allt RFX:en tar emot. Iaf ser det ut som om det kommer ren ASCII när man kör konftoolet.

Tillbaka till OWFS; det du skriver om att owfs överlever men givarna försvinner tycker jag talar för elektriska problem med bussen eller busmastern. Har någon gång drabbats av att måsta koppla loss hela nätet och ansluta en givare för att få igång det igen - kanske har bussen laddats upp och någon spänningsnivå förhindrar signaleringen? En koaxial Ethernet-buss skall ju termineras med 50 ohm i varje ända och en av ändarnas skärm skall jordas medan 1-wiren endast termineras av busmastern och dess givare...

Om möjligt prova med en annan busmaster - själv har jag en reserv liggande på hyllan. Mitt första stora problem resulterade i att reserven fick gå in permanent och ta över 50% av bussen/givarna. Hade väl kommit upp i kanske 50 meter och 10-15 givare när störningarna blev för stora; att dela nätet blev en enkel fix. Har nu en ny reserv inköpt...

Kolla gärna även statistiken som OWFS lägger upp på /mnt/1wire/statistics/... - har du mycket fel där lutar det åt problem med det elektriska...

Så här ser mina siffror ut efter 10 dagars körning (bortse från NET_connection_errors; de berodde på att jag tillfälligt stängt av owserver för den ena bussen)

Beräkningar

Skärmavbild 2016-01-31 kl. 16.36.54.png (41.24 KiB) Visad 11262 gånger

Statistik från OWFS

[zingo]

Hejsan,
har varit bortrest några dagar så det har gått på autopilot under tiden.
Tack för dina förslag till felsökning nedan.

Har själv sporadiska problem med en RFXTrx433 (inte den nya E-varianten) och fick lägga ned försöken att styra lite UPM-relän som jag fick av en kompis som inte längre behövde dem. Har en handfull 433 MHz givare som oftast, men inte alltid fungerar. Tror att den externa GP-antennen hjälper något med räckvidden, men att det är något som periodvis stör ut mottagningen för en av mina givare. Alla givare och mina grannar delar ju på frekvensen så det är väl inte omöjligt att någon av givarna hamnar "i fas" med en annan o de släcker ut varandras sändningar. Vidare verkar man inte köra med någon paritet eller checksumma, har någon enstaka gång fått +50 grader från en givare som ligger i en frys...

Ok, jag har inte heller känt mig helt nöjd med RFXtrx433, ibland kan den gå bra men sen kan den verka näst intill döv utan att något speciellt är ändrat. Jag hade tänkt ha den för att ta emot signaler från sensorer, t.ex Nexas IR-sensorer som jag har några uppsatta utomhus för att tända lampor o plinga i dörrklockor. Men det har väl gått sådär...

Du känner väl till RFX-toolen som du konfar och kör in ny firmware, etc med? Tror faktiskt att man med ett terminalemulatorprogram (t.ex. minicom) och genom att öppna "/dev/ttyUSB0" mot burken får se allt RFX:en tar emot. Iaf ser det ut som om det kommer ren ASCII när man kör konftoolet.

Yup, jag har uppgraderat f/w i den ett par gånger men har inte tänkt på att kolla vad som kommer ut ur kontakten med ett vanligt terminalprogram, det kan va intressant!

Tillbaka till OWFS; det du skriver om att owfs överlever men givarna försvinner tycker jag talar för elektriska problem med bussen eller busmastern. Har någon gång drabbats av att måsta koppla loss hela nätet och ansluta en givare för att få igång det igen - kanske har bussen laddats upp och någon spänningsnivå förhindrar signaleringen? En koaxial Ethernet-buss skall ju termineras med 50 ohm i varje ända och en av ändarnas skärm skall jordas medan 1-wiren endast termineras av busmastern och dess givare...

Sant men som sagt, jag har det bara på bordet just nu med ett par dm busskabel... Det andra nätet som används för olika saker funkar rätt stabilt, det här är just reservprylarna som jag labbar med Så att det skulle va nåt fel på sakerna, det tror jag inte, men visst allt kan hända...

Kolla gärna även statistiken som OWFS lägger upp på /mnt/1wire/statistics/... - har du mycket fel där lutar det åt problem med det elektriska...

Bra tänkt, det hade jag faktiskt inte kollat förut. Men det är 0 i praktiskt taget alla värdena, det enda som har något annat är CRC8_tries som är 33 men i övrigt är allt 0. Vilket det väl borde vara med så lite saker och så kort nät.

Så här ser mina siffror ut efter 10 dagars körning (bortse från NET_connection_errors; de berodde på att jag tillfälligt stängt av owserver för den ena bussen)

Intressant, vad får du de snygga färgglada utskrifterna från? Jag kollade på värdena från kommandoraden...

Men, för att återgå till problemet så har det gått bra och stabilt nu en vecka och det går att skriva till displayen utan att det kantrar. Även RFXtrx verkar ha fungerat under veckan när den fått vara i fred...

Det enda jag ändrat på är att jag installerade ett färdigt owfs-paket istället för den owfs som jag kompilerat själv. Men arbetet fortsätter

Tack för tipsen!