Automatic cat litter box.

What happens if you set Puck.increaseMTU = false before connection? It's possible that earlier Espruino builds had issues with the increased MTU?

The Puck.js lib will try and increase the MTU if it sees that it receives data in chunks of more than 20 bytes (because it assumes that for that to happen the MTU must have increased) and it's possible that it causes problems?

It'd be well worth trying with a newer firmware though, as I know there were some instability issues that have been fixed - 2.14 is quite old now

just have a led blink on every loop on the device, and force a bad signal on the phone running the web page.

which loop do you mean is there some specific looping code you can link (your code or that puck.js)? One idea is watchdog - if you have watchdog kicking in setInterval then any busy loop or delay in native code preventing intervals from running could trigger such reboot. Another issue causing this may be be overflowing the stack or memory - generating data faster than it could be sent filling memory or call stack (by somehow nesting calls when error happens?)

I will try if you cannot replicate it there, the version on dsd6 indeed only has standard BT packet length, but if the signal is good, it works fine for days connected. I only realized because I was getting random reboots, and could not figure out why. It turns out, I was not closing the connection from the phone, and when I was moving a floor down the toiler that was upstairs was rebooting :)

I can demonstrate it for you if you like, I was able to make the empty cycle run slower just by placing the phone between my legs so that the signal got worse.

I swiched to using characteristics and standard web bluetooth connection, and the problem is gone now for me, but I will make a small video if you believe it is usefull. If you are sure it does not affect newer vesions, then it is not problem.

I used the code Gordon has here(*), the write command I was sending to espruino for the loop was this one insted of the one on the example, so it was quite big, not as big as it looks ofcource, I was just returning the id and numbers,a json, but is was not a problem at all if the signal was ok, the script (http://www.puck-js.com/puck.js) was handling it nicely, only when signal was near lost the dsd6 was rebooting. 150 ms interval.

if you use this github example on a phone with an espruino device, and add some code so that you can see a led go on and off at every interval run on the device, you will see it blinking slower as you make the make the signal worse. If not, then it is strange, maybe it is an older problem, but it sounds strange that it not known, even if solved.

connection.write(
        "lal=setInterval(function(){Bluetooth.pr­intln(JSON.stringify({dt:Date().toString­().split(' ')[4],uv:scata.state.def.auto.uvc,ps:sca­ta.state.is.sys.pause,bs:scata.state.is.­sys.busy,db:scata.state.def.is.dbg,ac:sc­ata.state.def.auto.clean,ad:scata.state.­def.auto.delay,rtod:scata.state.is.sys.r­un,pos:scata.state.is.pos.ball,pwr:scata­.state.is.sys.pwr,lit:scata.state.is.vol­t.litres,pbv:ew.is.ondcVoltage(),ss:scat­a.state.def.sandType[scata.state.def.is.­sand].speed,sp:scata.state.def.is.sand,c­b:ew.is.batt(),pb:ew.is.ondcVoltage(1)})­);},150);NRF.on('disconnect', function() {clearInterval(lal)});\n",

(*)https://github.com/espruino/EspruinoDocs­/blob/master/tutorials/Web%20Bluetooth%2­0Dashboard.md#realtime-dashboard

I will make an example and will upload a link so that you can both test if you like, it is easier, sory for the long posts.

you will see it blinking slower if you make the signal worse.

Oh, ok - well that's expected I think. It's not really a crash.

What's happening is you're writing a bunch of data, but because the signal strength is bad it's not able to send all of that data quickly, so at some point you call Bluetooth.println and rather than lose data it waits patiently until enough other data has been sent that it can fit the text in the buffer.

Put another way, if you did Bluetooth.println with 10,000 characters of data, you'd hope that you would receive all that data - even though it wouldn't fit in the output buffer and the Bluetooth.println function might take a while to complete. It's the same sort of thing.

Probably using raw characteristics fixes it for you because if you try and write when too much data is backed up, it just throws an exception and carries on (rather than waiting)

I'd replace setInterval by scheduled setTimeout, it is fixed to 100ms here
https://github.com/espruino/EspruinoDocs­/blob/master/tutorials/Web%20Bluetooth%2­0Dashboard.md?plain=1#L214
so if sending (the Bluetooth.println(..)) takes longer than 100ms it may overflow and reboot(?). it is safer to schedule it again via setTimeout after println returns.

Oh, ok - well that's expected I think. It's not really a crash.

nice, yes that is was I understood was happening, I was overdoing it, was gettting greedy because I was playing with your tiny dash and it was fun :)

thanks, sory for not making my self clear, it is not a problem for me, I actually swiched to running NRF.updateServices 16 times per 1 sec, one variable after the other, and only send the ones I want to be instant every 100ms, while running all the rest of the code for the toilet empty cycle, and your amazing software is not breaking a sweat on the dsd6 :)

https://github.com/enaon/sCat-a/blob/910­9221dd977e7d7467cf9cbc1442445a11c7e53/ap­p/main.js#L16

it is safer to schedule it again via setTimeout after println returns.

actually I did not check how setInterval is done, but I always had issues when code in setInterval run longer than the interval. Since the interpreter is single threaded it won't run the code again if it did not finish but maybe it runs again right after previous one ends not giving chance to any other code or idle loop to run? So maybe GC is not done or other intervals may not run (pinging watchdog in this case) etc?

this is a run cycle I just recorded, I like your tiny dash :)

when it starts the empty cycle, the main gauge goes from powerbank battery reporting to ball placement reporting, you can see the empty cycle movement. Thanks again

https://www.youtube.com/watch?v=mo4dGIFl­VFU

When the bt signal goes low or near lost, the espruino device reboots

So is it that problem? That sounds a lot more serious than just a delay to me...

I always had issues when code in setInterval run longer than the interval. Since the interpreter is single threaded it won't run the code again if it did not finish but maybe it runs again right after previous one ends not giving chance to any other code or idle loop to run?

It should work ok - it tries to rechedule as soon as possible, but only after processing inputs and running through other intervals I believe. I guess it's possible if the first interval adds a timeout/interval itself it might trigger a re-run which might cause the behaviour you're having?

So is it that problem? That sounds a lot more serious than just a delay to me...

I believe so, I was able to make the dsd6 run slower just by making the signal worse, and eventually it was rebooting when using puck.js.com script. But I did not want the cli to be exposed anyway, so the NRF.updateServices solution is better in any case for real use, I did not investigate further. I can try something if you like though, I have a nice visual feedback of the delays to reboot sequence, the ball moves slower and then stops :)

but I do not have the probem anymore, the NRF.updateServices way solved it for me.

I can try something if you like though

Thanks, but I wouldn't worry - it's older firmware so it'd be hard for me to track down here (it could already be fixed if it is an issue). Glad you found a way around it though!

In a way it'd be nice to have a way to easily check how full the output buffer was, but doing setTimeout after as @fanoush suggested is nice and easy :)

Thanks, but I wouldn't worry - it's older firmware so it'd be hard for me to track down here (it could already be fixed if it is an issue). Glad you found a way around it though!

nice, yes fanoush's solution sound fine, I will try it next time I want to use the puck.js script. I had one more problem with it though, in your git example there was not a disconnect on lost signal event, it was not disconnecting when signal was lost, so I used the google way to be sure, disconnect due to low signal works fine with the google example. Next time I will ask for info :)

this is what I am using now
https://github.com/enaon/sCat-a/blob/910­9221dd977e7d7467cf9cbc1442445a11c7e53/in­dex.html

it is served from github from this page.
https://enaon.github.io/sCat-a/

sCat-a in greek sounds like shit, poop etc, in case someone wonders about the name :)

So maybe GC is not done or other intervals may not run (pinging watchdog in this case) etc?

nice, most probaby this was the case, I do have a watchdog that only needs 5 secs to fire, because the button on the dsd6 resets every 6 seconds or so, and I want to trigger it manually if needed.