@Drumline18 - Happy happy New Year too to you! ...and growing positive experience w/ Espruino in 2020 and many years following...
It is - in your case -
1st) not about how the save() works but - unfortunately - many of the example take not into account that create or connect_to or create_by_connecting_to set state in the connecting software component and/or the peripheral device itself that cannot be saved by Espruino and later restored on power cycling.
2nd) about possible trouble beyond your dealings because some of the peripheral devices lack a bit quality or convey information as clearly as possible (as this particular device @Robin was working with at that particular time).
Nobody doubts you feeling confident dealing with everything else. Believe me, it * IS * very frustrating that something is just not doing what one thinks it should do and even has doing it before, but for no obvious and more so obscure reasons it's just not doing so.
I really appreciate your venturing from Arduino into Espruino... I made significant investments - money and more so time in getting things going even with precursors of the very successful Arduino... but they had to clear stage the moment Espruino showed up. Having a flexible and logically powerful - high level and easy to use - language and very easy to use IDE at hand did not need much conviction... after all I liked Smalltalk, and JS was the new similarly power full world / platform after major entities abandoned the st ship in the war of SUN/Java and MS/... hype.
Spending countless hours on details others just left out ore did not think of to matter made me chip up the few extra bucks to buy Espruino hardware for which the Espruino Firmware and Software was built for and match up to @Gordon's standard and leave possible experiments for later... Some of these experiments were very disheartening because even among boards from the same source/manufacturer(?) were go and no go differences. It took me several attempts to get the Espruino on ESP8266 ESP-09 - 1 powerful cm2 going... and I would consider myself not unaccustomed to low level challenges from the Z8 and ubicom times doing similar things that at that time were more bleeding than edge.
Regarding use of ESP8266EX as a platform is a challenge since the Wifi stack has hard, non-negotiable demands and spending my time to work around these (in a non-commercial) setting I consider for myself not being the most effective use of my (life) time (left to me). Kind of 'oximoronic' though and not completely self less, I rather spend that 'saved' time in helping / enabling others to have success, even if it is not my way.
Since dedicated controllers are so readily available - almost every sensor has one built in - why should I not follow the same pattern? Use dedicated controllers for communication and (high level part/congtrol of) application rather than cramming all (cycle needs) into one single processor. Therefore, I prefer a combination Espruino (or a-like) hardware for the application with a communication hardware such as the ESP866EX.
Btw, I liked your abstraction layer for pin mapping... and it almost made it there. Even though I see portability / adaptability / moving on to new platforms is not the primary aspect for - dedicated -micro controller software, it is always nice to not be prisoner and being locked into a particular setup.
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
@Drumline18 - Happy happy New Year too to you! ...and growing positive experience w/ Espruino in 2020 and many years following...
It is - in your case -
1st) not about how the save() works but - unfortunately - many of the example take not into account that
create
orconnect_to
orcreate_by_connecting_to
set state in the connecting software component and/or the peripheral device itself that cannot be saved by Espruino and later restored on power cycling.2nd) about possible trouble beyond your dealings because some of the peripheral devices lack a bit quality or convey information as clearly as possible (as this particular device @Robin was working with at that particular time).
Nobody doubts you feeling confident dealing with everything else. Believe me, it * IS * very frustrating that something is just not doing what one thinks it should do and even has doing it before, but for no obvious and more so obscure reasons it's just not doing so.
I really appreciate your venturing from Arduino into Espruino... I made significant investments - money and more so time in getting things going even with precursors of the very successful Arduino... but they had to clear stage the moment Espruino showed up. Having a flexible and logically powerful - high level and easy to use - language and very easy to use IDE at hand did not need much conviction... after all I liked Smalltalk, and JS was the new similarly power full world / platform after major entities abandoned the st ship in the war of SUN/Java and MS/... hype.
Spending countless hours on details others just left out ore did not think of to matter made me chip up the few extra bucks to buy Espruino hardware for which the Espruino Firmware and Software was built for and match up to @Gordon's standard and leave possible experiments for later... Some of these experiments were very disheartening because even among boards from the same source/manufacturer(?) were go and no go differences. It took me several attempts to get the Espruino on ESP8266 ESP-09 - 1 powerful cm2 going... and I would consider myself not unaccustomed to low level challenges from the Z8 and ubicom times doing similar things that at that time were more bleeding than edge.
Regarding use of ESP8266EX as a platform is a challenge since the Wifi stack has hard, non-negotiable demands and spending my time to work around these (in a non-commercial) setting I consider for myself not being the most effective use of my (life) time (left to me). Kind of 'oximoronic' though and not completely self less, I rather spend that 'saved' time in helping / enabling others to have success, even if it is not my way.
Since dedicated controllers are so readily available - almost every sensor has one built in - why should I not follow the same pattern? Use dedicated controllers for communication and (high level part/congtrol of) application rather than cramming all (cycle needs) into one single processor. Therefore, I prefer a combination Espruino (or a-like) hardware for the application with a communication hardware such as the ESP866EX.
Btw, I liked your abstraction layer for pin mapping... and it almost made it there. Even though I see portability / adaptability / moving on to new platforms is not the primary aspect for - dedicated -micro controller software, it is always nice to not be prisoner and being locked into a particular setup.