Jag är helt enig med dig att man lätt får problem om samma relä styrs manuellt och triggas vid larm. Men detta är ett problem oavsett om man lägger in en minnesfunktion för status före omstart eller ej. Och jag förstår inte hur en minnesfunktion kan trassla till det. Den säkerställer ju bara att reläet intar samma status som det hade innan omstart. Detta oaktat vem  som sist påverkade reläet.

Jag tycker att användaren kan hålla rätt på om ett relä är kopplat till larm och då bör man undvika att styra manuellt. Vill man göra detta extra säkert kan man utöka med en funktion där man allokerar reläet till larm eller manuell styrning. Kopplas det till larm går det inte styra manuellt. Och vice versa. Men detta är överkurs. Vill mycket hellre ha minnesfunktionen.....

Tror du missförstod mig.  Alla funktioner som påverkar reläet gör detta via en och samma rutin som speglar relästatus i NVRAM. Larm och manuell styrning hanteras på samma sätt. Rutinen kommer bara garantera att reläet inte ändrar status pga någon glitch vid omstart.

Självklart kan det bli problem om samma relä styrs manuellt och av larm, men mitt förslag påverkar inte detta till det bättre eller sämre. Den säkerställer bara att inte någon ytterligare aktör (glitchen) inte ändrar relästatus permanent. Glitchen använder ju inte rutinen!

manliga?

man lita.... Det blir inte alltid rätt på telefonen....

Största problemet är det jag skrev ovan, att det skulle kollidera med när reläerna styrs via solfångarstyrning och larm.

Vet inte hur denna styrning är implementerad. men jag antog att såväl solfångarstyrningen och larmfunktionen manipulerar reläerna genom mjukvarufunktioner. Om man då använder de funktioner jag föreslog, så kommer alltid att senast relästatus garanteras efter omstart, oavsett varifrån styrordern kommer.

Funderat lite mer på problemet. Tycker att det inte borde vara så svårt att lösa problemet i mjukvaran. Kapsla in relästyrningen i en funktion som speglar relästatus i NVRAM. Styrningen av utgångar får bara skötas av den rutinen. Efter omstart sätts relä till lagrat värde i NVRAM.

Men det är klart om det är många ställen i koden som direkt manipulerar reläerna kan det bli lite jobbigt att hitta dessa och ändra överallt...

Ok, lite besviken är jag. Det finns inget i beskrivningen av I/O modulen som indikerar att man inte manliga fullt ut på dessa utgångar. Eftersom jag övervakar temperatur och energiförbrukning får jag en indikation om att något är galet om värmen slår ifrån. Kan tom får ett larm antar jag. Så jag står inte och faller med funktionen. Använder den för att sätta på elvärme något dygn innan vi åker till stugan på vintern. Grundvärme står på hela tiden. Väl på plats kan jag slå om till manuell styrning.

Jag har alltså en A/DMIQ modul ansluten, och den har 2 relä-utgångar. Dessa kan styras från e-logger under 
"utgångar" på inställningsmenyn. Får inte dessa användas för styrning??

Vad ska de då användas till??

Jag har anslutet en expansionsmodul för att kunna styra 2 digitala utgångar till min logger. Det fungerar utmärkt, så när som att jag inte alltid kan lite på att inte status för dessa ändras. Jag använder dessa föra styra värmen i huset och en värmepump för en pool. Emellanåt (någon eller någon månads intervall) så slår utgångarna ifrån utan att jag har ändrad något på e-logger. Inatt hände detta igen och igår kväll noterade jag att jag tillfälligt inte hade någon kontakt med loggern via internet. Avbrottet hade då varat några timmar. Idag på morgonen var anslutningen återställd och alla data finns där (buffrades antagligen i loggern), men nu var värmen avstängd då bägge utgångarna var inaktiva.

Detta har hänt några gånger tidigare, men jag kan inte med säkerhet säga att jag har haft ett avbrott i förbindelsen när detta har hänt. Men jag vet att jag haft sådana tillfälliga avbrott med någon/några månaders mellanrum, men det är inte osannolikt att problemen är kopplade till sådana tillfällen.

Jag kan nämna att en klockströmbrytare startar om routern varje natt för att försäkra mig om att den inte ställer sig i hörnet.

Det känns inte helt bra att jag inte kan lita på att utgångarna inte ändrar status av sig själv.

Verkar som att e-logger loggar med felaktigt klockslag. Den rullande klockan indikerar 21:28 samtidigt som senaste mätning 19:10 (eller liknande). Timern räknar ner prydligt och jag e-logger registrerar en ny mätning.  Jag får intrycket att det är någon vajsing med tiden. Eller så buffrar e-logger data ett par timmar innan senaste data finns tillgängligt i graf och tabell.

Edit: Inser att e-logger inte presenterar alla data. Nu uppdaterades data i tabellen med korrekt klockslag. Inget fel alltså!

Problemet är att det inte går att bryta strömmen! Den har ett inbyggt batteri. Ser ut som en mycket liten telefon. Suveränt praktisk som wireless hub om vill dela internet på en konferens t.ex., men som router för telemetri är den värdelös! Det laddningsbara batteriet räcker i timmar!

Nu har jag gett upp och kastat ut denna router. Värdelös för e-logger, då man inte enkelt kan få igång 3G-länken genom att bryta strömmen om problem uppkommer någon gång. Köpte istället en TP-LINK MR3420, och den har alla feature man behöver. Fungerar klockrent!

Jag har tänkt tanken, men problemet är att jag inte får död på modemet som har inbyggt batteri (laddningsbart och går inte att ta bort...). Insåg nu att jag hade gjort ett misstag och glömt starta om routern efter DHCP-ändringen. Så fortfarande har jag ett litet hopp att jag kan få det att fungera....

Fortsättning följer!

Och här kommer fortsättningen: Det verkar fungera! Efter någon timme så verkar routern släppa adressen och lämnar ut den på nytt till loggern. Så får jag ett strömavbrott som leder till att loggern startar om så dröjer det ca 1h innan kontakten är etablerad igen. Det kan jag stå ut med. Enda smolken är att jag inte kan använda modemet för någon annat än loggern, men även det kan jag leva med tills den nya programvaran blir klar!

Nu är jag hemma igen och har gjort ett nytt test med att sätta ner address range till 1 adress i DHCP servern. Satte sedan time-out till 1min, så att den släpper adressen om den inte förnyas var 30s eller något liknande. Trodde att jag skulle komma runt problemet på detta sätt, men icke som icke. Det verkar som att routern fortsätter hålla uppe WAN-länken (3G) även om LAN-länken kopplas ner. Och DHCP-servern släpper inte adressen, varpå loggern blir hängande vid nästa anslutningsförsök då det inte finns fler adresser att lämna ut. Det ser ut som att jag måste stänga av routern och slå på den igen, för att loggern ska få en ny adress.

Tacksam för om du skickar mig ett PM när en ny programvara finns att testa. Ser inte att jag kan få det fungera stabilt med kombinationen Huawei E5 och loggern.

Skälet till att jag skaffade denna router var att jag fick den billigt samtidigt som jag tecknade ett lågpris mobilt bredbands-abonnemang hos Tele2. Min gamla 3G-router (DLINK) var allmänt instabil och fick startas om med jämna mellanrum förra att hålla uppe 3G förbindelsen. Jag behövde också ett separat abonnemang för sommarstugan.

Som sagt, enheten är väldigt liten och käck men inte speciellt begåvad. DHCP reservation lyser med sin frånvaro och den verkar också sakna stöd för uppgradering av programvaran. Som sagt den var billig....

Tror mig också förstå lite hur DCHP servern fungerar. Om jag bara rycker LAN-sladden och sätter i den igen efter en stund, så får klienten tillbaka samma adress. Om jag däremot startar om klienten däremellan, så verkar DHCP-servern ta det säkra före det osäkra och dela ut en ny adress. Om jag startar om såväl modem som klient samtidigt, så kanske det ordnar sig med att den delar ut första adressen igen. Kruxet är att den lilla rackaren är utrustad med ett laddningsbart batteri och kör bara vidare som inget hade hänt vid ett strömavbrott. Och sådana händer på landet med jämna mellanrum. Alltså kommer detta leda till att jag kommer i otakt med adresstilldelningen.

Prövade att sätta ner DHCP range till en adress, men det slutade med att routern blev onåbar totalt, då den verkar hålla på den först utdelade adressen och kan inte dela ut någon ny. Ska göra ett sista försök och sätta ner release timern till ett lågt värde i kombination med att bara dela ut en enda adress. Då släpper routern förhoppningvis den först utdelade adressen efter att timern slår, och kan dela ut samma igen. Ska prova detta nästa vecka. Jag är på resande fot nu. Men långsiktigt är detta inte någon bra lösning då jag inte kan använda routern till något annat än att ansluta loggern.

Annars kan jag tänka mig att testa den nya programvaran under ordnade former i hemmets lugna vrå under någon månad. Min känsliga router verkar vara ett utmärkt testobjekt...

Hej,

Efter att ha klarat ut mitt problem med felaktigt ID, håller jag på att bryta ihjäl mig för att få routern att dela ut samma adress till loggern efter ett strömavbrott. Routern har dessvärre inte någon funktion att reservera IP-adress till speciell MAC-adress. Det märkliga är att routern verkar vara konsekvent när den delar ut adresser till olika PC som jag ansluter, men inte till loggern. Om jag bara kopplar loss kabeln och sätter tillbaka den efter en stund, så verkar det gå bra. Bryter jag strömmen är det värre, då får jag en ny IP. Ibland nästa högre adress, eller så börjar den om på första adress i DHCP serverns adressområde. Om den bara hade varit konsekvent och alltid tog första adressen så hade jag varit jättenöjd, men icke.

Det funkar ju inte att hela tiden hålla på att jaga vilken adress loggern fick och ändra port forward därefter.

Andreas, du nämnde något om en ny mjukvaruversion, där man inte ska behöva ska behöva öppna portar. Då borde det fungera med vilken lokal adress som routern behagar dela ut. Är denna på gång i närtid eller?

Jag som hade tänkt få till övervakningen i stugen till vintern, men det har gått troll i detta....

Jo, jag kan sätta reservationstid och därmed förhindra att adressen byts, men vid ev. strömavbrott kommer det skita sig är jag rädd. Ska pröva dubbla DHCP servers på nätet och se om detta är en framkomplig väg. Men den känns sådär om jag ska vara ärlig.....