After few days of work I can no longer connect to my puck

Hello
I had my puck running for 3 days without an issue as a power meter.
But then it stopped reading the data as a power meter and I can no longer connect to it.
It still sends current battery and temp statuses.
When I try to connect to it I get this:

Disconnected from Web Bluetooth, Puck.js 1c30
Unable to retrieve board information. Connection Error?
Connected to Web Bluetooth, Puck.js 1c30 (No response from board)
You have pre-1v96 firmware. Upload size is limited by available RAM
Prompt not detected - upload failed. Trying to recover...
 

Have you tried connecting from a different computer, or just restarting your computer?

Sometimes the browser/bluetooth stack on the PC can get confused and will refuse to connect - it might not be the Puck at all

Tried various things - none help. Only hard reset is working.
I have also tried to play with E.reboot() to clear the RAM (reload the code) but as soon as it reboots I can no longer connect to it as well

PS: OK, worked out the part where I cannot connect to it. It must have done a reboot or whatever, which has caused this to kick in:

NRF.setSecurity({display : 1, mitm : 1, bond : 1, passkey : '123456'});

If you start up the Puck holding BTN1 down then it shouldn't run any code whatsoever and will also clear out any saved pairings. At that point you should be able to connect and run require("Storage").eraseAll() to completely clear everything out and return it to a 'factory fresh' state

it does not seem to be RAM related. I set it to reboot every night but having an issue with it getting stuck due to the stupid LED light on the meter staying on and somehow making LDR to cause the puck to hang after a while
Currently, it is checking (as you have suggested) for stuck LED and sets the PIN mode for D2 to either input_pullup or input.
Are any of the PIN modes more useful to reset it? like pin.toggle() or something?
It works for some time, but eventually somehow gets stuck in the state that stops everything.
If I remove puck from the light source, thus causing it to "unstuck", it reboots the puck and then works fine

Is it possible that you've just got an almost flat battery? If you did then the increased power draw from the LDR when the light was on would drop the voltage so much that the Puck stopped working?

thought so too but it's only 2 days since I put a fresh battery in. After I removed puck from the meter box and stuck LED (which was not really stuck and went off after about 10 sec) puck started working again and I was able to see/connect to it without removing the battery. When I could connect, battery was showing 50% and went up to 60% a bit later on

I am giving up on Puck =(
When it works, it is reliable (apart from the battery drain, but that could be due to the LED stuck on)
But after some time it just goes off the air and no way to connect/restart it remotely. The only fix is to yank the battery out. Gave up on the battery option and using a cable to 3.3v out on the ESP32 board that sits in the same box (as BT was not powerful enough to be read from outside the metal box, though WIFI on ESP32 is ok, which uses the same frequency). But still no luck - works for a few days and then just dies.
I have added nightly reboot already, just to clear any RAM/cache issue it may have. So running out of options. Given that I have ESP32 by the meter box anyway, I will just have to modify the code and use ESP32 as a main device

Hi,

Sorry about that. Honestly I'm not sure what to suggest - that system has been working for months here just fine.

Only thing is, is it possible that some other device is trying to connect to the Puck?

@user130485

I assume you are talking about the DiY Smart Meter from https://www.espruino.com/Smart+Meter - and - some additional code and wiring (or BLE), that talks to the ESP32.

My initial thought was that on uploading the code and on start up / init, something must fall between the cracks - not clean setup with all in onInit(), or in cooperation with the other device something with the sequencing creates an issue. Looking at the example, all happens in onInit() (at least what the espruino example shows... except the creation of the Counter).

A last ditch effort could be in taking a more subtile approach on detecting a pulse of the meter LED. In a nutshell: have a state machine that uses falling as well as rising non-repeat watches and monitors the state changes with additional, separate timeouts. This would allow to detect meter's LED staying on too long for being counted as a pulse for counting (on because the is busy with communication... which also throws a shadow on the accuracy of the setup of counting blinks).

An additional option is to control the 'powering' of the LDR: set D1 high to end a stuck cycle.

After a power-meter-LED-on-for-too-long cycle, I assume, the power meter returns to normal blinking.

Yes, it was based on the Smart Meter but with a heap of extra code to optimise it for my situation. ESP32 is just a BLE receiver that sends the data to Home Assistant.
It's suppose to get unstuck. I have already implemented some routines with Gordon's help to get past the stuck LED state plus I am restarting it nightly in a hope to clear whatever issues happen during the day. So far 2 days gone ok without issues
@Gordon Highly unlikely. Its in a metal box where smartmeter is. I could not connect to it from the room, so had to get my ESP32 board in the same cabinet as the smartmeter. But agree, it was a plausible suggestion. Problem is that I cannot connect to it with anything - it no longer sends the data and not visible in BT devices to connect via IDE
I just don't know how to debug it so that I know what when the issue happens

I have uploaded the full code to pastebin, if someone interested
https://pastebin.com/rQuaKiKd

Thanks - looking at the code, you do stop it sending its name over Bluetooth. Usually that would be ok and you would just see the MAC address but in order to find it the IDE then uses scan response data, which can be a bit unreliable if there is a bunch of Bluetooth traffic. I guess that could be it? When you can't connect, can you still see it advertising with the NRF Connect app?

One way to debug is to add a USB-TTL adaptor so you can always communicate with it regardless of Bluetooth state. That really increases power draw though (1mA) so it's something you'd only do for debugging.

One other thing is you could add a watchdog timer. It's super unlikely that you would ever have a lockup, but at least if you do add the watchdog timer you could rule that out

Thank you @Gordon for helping me out =)
When it disappears from the air, I cannot see it with anything. Plus it's not sending anything out.
Can you elaborate on the watchdog timer?
Power draw is not important as I am currently running it via mains power (over esp32 3.3v output)
May have to solder the wires for TTL output to use when goes off-line again

No problem! If you need it, the connections are at http://www.espruino.com/Puck.js#serial-console

For the watchdog timer you just need http://www.espruino.com/Reference#l_E_enableWatchdog

So if you do E.enableWatchdog(2); then if Espruino crashes such that it's not executing anything in setInterval, it'll automatically reboot.

You can go one step further and manually poke it in your code, so you know that if your code doesn't execute that line in X seconds the device reboots:

E.enableWatchdog(1, false);                                                         
setInterval(function() {
  if (everything_ok)
    E.kickWatchdog();
}, 500);

You just need to watch out that if you go to update the firmware the watchdog will still be running and may cause a reboot if it isn't enabled in the new bit of code you update.

As I said above though, one reason you may not see it advertising is if some other device has automatically connected to it.

You could always add setWatch(()=>NRF.disconnect(),BTN,{repeat:true}) so when the button is pressed it disconnects from whatever it is connected to, and that might help?

@user130485

downloaded your code and gave my understanding of it a shot...

Three things that bothers me about the code are:

1. What are the prints still do? May be I missed the memo that it does not matter anymore for the console buffer to get full...
   
2. The intervalled function checking for meter LED stuck on keeps going, and since its code messes with D1 and D2, it may mess with the actual process. (see also 3.).
   
3. A clearWatch() without arguments seems never to be fine with me (same as clearInterval() and clearTimeout() with no arguments have undesired effects).
   
   

And there is a 4th thing - not really adding to the code - is the source formatting... if it is structurally off, I get mislead in the logic... So my first action was to adjust it to support my (human) reading abilities and my understanding what happens when and in what relation to other sections of the code.

Regarding code design: setInterval() is very powerful and allows straight forward and very concise code. Unfortunately, the outside world that we try to catch with the intervalled code is 'not so intervally', and thtt is why I usually resort to a monitored state machine: state machine for tracking the all state transitions, and monitored to detect irregularities in the timing of states and transitions.

Intervalled code is fine if it does not interfere with state. (Sure one can have gazillions of synchronization flags / semaphores, but that does make the code not more robust or components more loosely coupled).

was not meant to be a production code =) just something I was putting together for myself
Prints are just for debugging. I was under the impression that unless you actually connect to the console it will make no difference. Device is usually just passively sending the data via BLE and I only connect to it to see if all ok or to flash an update
When LED was getting stuck, it was draining the battery quickly. I was adding the code to minimize the drain.
clearWatch - as per API, if no parameter is supplied, all watches will be removed. This is just in the onInit stage and not used anywhere else. I think it was in the original code, so I just left it there
Did not understand the state part

thank you again @Gordon!
I will try both. I think its the watchdog that may kick in.
Again, I dont think another device would be able to connect to it. Currently I have the button set to change the status LED between on/off. When it gets stuck it does not work either.

I was under the impression that unless you actually connect to the console it will make no difference.

Yes, that's correct. The getting stuck with prints is an issue for USB devices if they're plugged into a PC but nothing is reading data - but it shouldn't apply to bluetooth