Svenska ElektronikForumet

Ficklampa som "simulator" för detta är nog inget bra alls.

Nä, det förstår jag men det var det jag hade närmast till hands just då.
Och det att Sparsnäs-displayen visade rimliga siffror gjorde att jag inte ordnade någon bättre lösning.

Men jag ska göra ett nytt test med en pwm-styrd lysdiod när jag får tid igen.

EDIT: Jag kunde inte låta bli att testa lite mer i kväll, och med funktionsgeneratorn och en lysdiod så fungerar det perfekt nu. Ficklampssimuleringen var med andra ord boven i dramat.
2 Hz och 20 % pulsbredd ger mig 7200 W vid 1000 imp/kWh nu ganska konstant, skiljer ett 10-tal W ibland bara.

För mig I vissa situationer när IR-ögat såg ljus från visa vanliga belysnings-LED-lampor så uppfattades det ljuset som massor av pulser.

Gott att höra Zkronk, lät som en knepig bugg annars

Nu har jag stött på patrull igen...
Efter ett tiotal paket så slutar rapporteringen till MQTT-brokern. Ibland redan efter 3-4 paket, finner inget riktigt mönster.
Jag har verifierat via serieterminalen att ESP'n är vid liv och gör sitt jobb, men den verkar tappa anslutningen till Mosquitto.
Nätverksanslutningen är det inga problem med så vitt jag kan se, den svarar på ping i alla fall.

Utdrag från Mosquitto-loggen: EDIT: Efter lite mer funderande så ser jag att k15 betyder att keepalive-värdet är 15 sekunder (det är default-värdet för PubSubClient-biblioteket), och Sparsnäs skickar ju ut paket var 15:e sekund, och blir det någon miss och inget meddelande skickas exakt var 15:e sekund (okej, brokern lägger nog till lite marginal tror jag, med inte tillräckligt för att täcka upp 1 eller 2 bortfall) så blir klienten bortkopplad. Jag ska ta och testa att ändra på det och se om det är det som är problemet

Tror jag har liknande problem fast det händer efter nått dygn. Svårt att undersöka. Jag har för mig brokern är ställd på 10s och att de 5s upp till 15 är marginalen. Sen verkar det lite krångligt att ändra dessa värden.

Jag har provat att ändra MQTT_KEEPALIVE från 15 till 60 i PubSubClient.h nu, och så här långt (10 minuters test) har den inte tappat anslutningen någon gång.
Ska fortsätta köra och se om den håller sig stabil.

Är det av någon anledning förresten att den totala förbrukningen (kWh) trunkeras till ett heltal? När jag testade med rtl_sdr-varianten så fanns det ett gäng decimaler även på totalen...

Det gällande decimalerna på kwh vore intressant att lösa, blir rätt rejäla steg i graferna.

Någon annan som har problem med att ESPn wdt ar ?
Har testat att byta biblioteket som används till detta vilket jag förstår skall lösa liknande problem:
https://github.com/rrobinet/RFM69X_Library

Alternativt att min wdt ar för att jag gjorde ändring i hur den postar värdena till MQTT då jag fick 0 värden.
https://github.com/bphermansson/EspSpar ... y/issues/4

Hmm min kod använder inget lib?

Wdt Kan du få om koden "låser" för mycket. Du får tex inte ha längre delayer med en esp, då kan den inte göra det den måste göra i bakgrunden.

Ok jag kanske använder fel begrepp men det följer med RFM69registers.h och refereras på rad 35 i #include <RFM69registers.h>
Det var denna vilket jag menade var library (levereras normalt som ett "externt" library om man laddar ner det ifrån lowpowerlabs)
Har inte ändrat något annat än det jag nämnde i förra posten i din kod.

yield() kan man använda på ESP plattformen för att släppa kontrollen till underliggande processer så de kan hantera vad de behöver.

Ok då är jag med

Ja precis, och yield skulle kanske behövas?
Reset cause 4 är wdt reset.

http://www.esp8266.com/viewtopic.php?p=2096#p2112

Ni får ursäkta om det hoppar lite fram och tillbaka när det gäller ämnet i denna tråd, men jag tänkte återkoppla lite om de problem jag hade med att ta emot värdena från min sparsnäs.

Det är så att trots att jag beställde både 433 och 868-moduler av både cw och hw varianterna i början av december har jag fått hem allt utom 868cw. Det skall ju inte vara någon skillnad vad det gäller rx mode mellan dem så jag trodde det inte skulle spela någon roll att jag körde på hw istället för cw (som alla andra verkar använda).

Tyvärr fungerade det inte. I de första varianterna på github var det ju en esp12-modul som användes och jag körde med Wemos D1 mini vilket gör att jag fick 2 olika potentiella felkällor. Mycket tid lades på att verifiera vilka pinnar jag skulle köra på, och att det inte fanns potentiella krockar i användandet av pinnarna på wemosen kontra en ren esp12 modul. Det visade sig dock att det inte var några problem att använda wemos D1 istf esp2.

Jag kunde se att jag tog emot RF-data när jag slog på debugmode, en massa träffar blev det. Långt mycket mer än var 15:e sekund som sparsnäs sänder ut men jag kopplade det till mina zwave-prylar.

Jag labbade fram och tillbaka med parametrar och frekvenser, lade till en del extra debugkod för att printa crc samt innehåll i de mottagna paketen och fann att det inte fanns något vettigt mönster i det jag tog emot. Varenda crc var fel och datat helt slumpmässigt.

Jag började då misstänka att det var strul med SPI-kommunikationen. Frekvenser ändrades både på SPI-klockan och CPU-klockan till wemosen, Jag kunde dock konstatera genom att koppla in en logikanalysator att det jag skrev till konfigurationsregistren och den data jag läste ut överensstämde med de värden som skulla skrivas och det jag såg på mina debugutskrifter. Så det var inget fel på SPI-kommunikationen.

Härnäst började jag fundera på bitrate och frekvensdviation. Strigeus har lite annorlunda värden i sin orginalkod än den kod PHermansson har publicerat så jag testade fram och tillbaka med dessa värden. Tyvärr utan framgång.

Nu var det dags att börja med lite strukturerad felsökning. Jag körde igång min sdr-mottagare och sdr# och kunde ganska snart konstatera att det inte fanns speciellt mycket trafik i luften runt 868MHz. Ändå fick jag en massa interrupts då DIO0 på min RFM868HW indikerade payloadready. Hur kunde det komma sig? Var det brus som gav falska träffar?

Jag drog ner RSSITHRESHOLD jättelågt, ändå tog jag emot i princip lika mycket trafik. Det var något som inte stämde...

Nu vidtog en grundligt genomläsning an databladet för RFM69. Jag hittade då att det finns en skillnad på RX mode mellan CW och HW. HW har en timer som ger en interrupt om inte payloadready har inträffat på en viss tid.

RegRxTimeout2 (0x2B) interrupt is generated TimeoutRssiThresh *16*T bit after Rssi interrupt if PayloadReady interrupt doesn’t occur.

Det måste vara det som orsakar alla dessa falska värden jag tar emot.

Jag lade till följande i koden för att vara säker på att det var avstängt: Nu blev det bättre, antalet interrupts för payloadready minskade dramatiskt men inte helt till den nivå som motsvarade de aktuella sändningarna jag kunde se i sdr#.

Jag drog då ner RSSITRESHOLD
...och då försvann i princip alla falska triggers. Dock hade jag fortfarande inga riktiga värden utan det var crc-fel hela tiden.

Jag kunde se i sdr# att frekvensen inte riktigt var 868MHz, otan snarare 867,980MHz. Så jag lade in
Voila, nu funkade det perfekt!

Det var min resa, det är ju inte säkert att det stämmer om någon annan har problem med att få sin RFM69HW att funka, men det kanske kan vara en hjälp på vägen. Den viktigaste ändringen är nog att lägga in denn rad.

swapper skrev:Det gällande decimalerna på kwh vore intressant att lösa, blir rätt rejäla steg i graferna.

Tittade på koden nu och funderar på vad värdet total eg innebär? Total number of pulses skriver Strigeus. Sedan när? Hur är det relevant?
Siffran jag får via Mqtt kan jag inte hitta på displayen. Så jag undrar om detta eg bara är ett Kontrollvägen?

Intressant carpelux! Får ordna nån notering om hw-varianten. Och fundera på frekvensproblemet, Strigeus har ju en funktion för att hitta avvikelsen.

27 timmar utan att tappa anslutningen till MQTT-brokern hittills!
Angående kWh-visningen så kollade jag på koden nu och det är ju totala antalet pulser från att sändaren startades divideras med antalet impulser/kWh.

I och med att det är en int och en #define med ett heltal så blir ju svaret också ett heltal. Borde fungera att köra med type casting till float för att få ett decimalvärde där.