Avatar for allObjects

allObjects

Member since Jul 2014 • Last active Aug 2019

Espruino makes IoT as easy as 123!

Most recent activity

  • in ESP8266
    Avatar for allObjects

    I know that this conversation is in the 8266 realm, but - for curiosity - I just tested on a PICO, and that is what I get:

     ____                 _
    |  __|___ ___ ___ _ _|_|___ ___
    |  __|_ -| . |  _| | | |   | . |
    |____|___|  _|_| |___|_|_|_|___|
             |_| espruino.com
     2v04 (c) 2019 G.Williams
    Found PICO_R1_3, 2v04
    >
    Connected to /dev/cu.usbmodem14111
    >JSON.parse()
    Uncaught SyntaxError: Expecting a valid value, got undefined
     at line 1 col 10
    undefined
             ^
    > JSON.parse(undefined)
    Uncaught SyntaxError: Expecting a valid value, got undefined
     at line 1 col 7
    undefined
          ^
    >JSON.parse("")
    Uncaught SyntaxError: Expecting a valid value, got EOF
     at line 1 col 1
    ^
    >JSON.parse("{}");
    ={  }
    > 
    

    ...comparable what the (Chrome) browser JS Engine throws at me: see attached screen shot (...but is for sure not a crash of the system / HW).

    Workaround is asking if undefined before parsing... (try catch does not help)...

  • in ESP8266
    Avatar for allObjects

    Interesting... and even the board matters... (assuming the commit is for the built code..., which is the same for the latter two).

  • in ESP8266
    Avatar for allObjects

    Regarding the code:

    I do not understand lines 18..23... it also looks syntactically weird to me... may be something got lost in copy-paste... I'm also curious about the big indentation... must be some context.

    Regarding the text:

    open a Web server to get SSID and password

    Does that mean that something is 'polling/trying to connect to that Web server to come up and then requests a page to post the SSID and password to connect to a different network? ...because servers do not request things, they serve requests, they also do not send pages by themselves, the respond to requests with a page.

    stop listening on a Web server

    Do you mean stop listening to requests?

    Milling over my own question I guess I see what event you are locking for:

    The even of having sent the response in its entirety and only then you want to shut down the server.

    Are you thinking of the remote device operating in two modes:

    First mode - for setup / boot: it is an access point with 'static/fix' ssid, pw and web server that allows to be connect to and can receive a post with and other ssid and password for Second mode.
    Second mode - for regula operation: Connect as station to the network with ssid and password received in the first mode.

    Another comment I want to make is: when you are already connected to a wifi network w/ a particular SSID and password - I do not know if you can can create an access point, because an access point means defining a new network with its own, different SSID and password, and I do not know if you can operate on two networks simultaneously. But:

    If you have a Wifi connection, yes you can open a server and listen to requests and then shut it down after serving the pages / posts you needed to serve (to either provide data or get data, and use the gotten data to continue on the connection with something else (such as create a http request - to get a 'command' for execution, polling).

  • in ESP8266
    Avatar for allObjects

    @maze1980, it is very difficult to respond to conversations with such titles and with no details / context of the code and even less of the hardware...

    Main issue with most platforms - and especially non-Espruino boards - is that it matters what the setup is and happened before you issue save(), for example: is there level 0 code that creates things other than code objects... It is always good practice to have nothing set - such as pin modes - or activated - such as timeouts, intervals, connects, etc - except in onInit().

    A tanking - rebooting -ESP866 has usually two root causes:

    • power stability
    • cycle hogs in the application code
  • in ESP8266
    Avatar for allObjects

    @nhlives, nice concept of limit the time of operation to avoid run-aways. Do you have some imagery about how the ESP8266 is connected / mounted on some of the control device of the bed and other devices? ...You may know that Espruino runs also on sonoff and a-like that allow 110..220 main power control?

    Since power seems not to be an issue, there is no issue with wires 'all over the place'... and also no issue with power for driving servos, solenoids, etc. That's good to know. Understandably, because beds with these options are mains connected anyway, and if at home, they are not moved around either...

    Regarding the event you were looking for: 'finished' of what? - http comm? operation? etc.

  • in General
    Avatar for allObjects

    Integration boils down to 'who owns the pins and the other resources (timers, interrupts)...'. Espruino is usually standalone and owns it all in a very integrated way between hardware side and application / programming side... Similar is RTOS: it provides interfaces to the resources and the application has to use them... Mapping/connecting this underlaying resources into Espruino becomes an issue for time sensitive tasks, and both environments do not always share the same solution approach.

  • in ESP8266
    Avatar for allObjects

    I can easily second @Ollie in both: still to consider Espruino for the 'interface' between a local brain device and the things to control, last but not least because it is frugal power consumption, especially when you go BLE for communication - battery driven / cordless - and for the 'decent' local brain you go for a Rasp Pi that can be power connected all the time.

  • in ESP8266
    Avatar for allObjects

    EDIT of post #12: jetty instead of tomcat... https://github.com/eclipse/jetty.project­

  • in General
    Avatar for allObjects

    sure, for example - by manufacturer - https://www.raytac.com/product/ins.php?i­ndex_id=31 - as by all MDBT42Q BLE based modules... and Espruino Original and Pico boards (CE ROHS)...

    Non-Espruino sourced boards - where Espruino firmware runs on, for exmple espressif chips, modules and boards - as per manufacturer's specs: yes - CE FCC ROHS.

    For complete information, pls contact @Gordon

  • in ESP8266
    Avatar for allObjects

    Alexa/Google sends a turnOn request to our backend. We pretend to be be a switch. The request goes into a LIFO queue via a https GET. The 8266 bed controller polls using a https GET. The remote web site returns the latest request and deletes any older ones. The 8266 does what it needs to do to operate the bed.

    The terms our backend, We pretend, FIFO, ...this is all a site that is available for all the registered HW control devices to pull from? Neat solution.

    To overcome the issues of polling can be overcome by NIOB - non io blocking http(s) application server and long lasting http(s) GET requests.

    Quite a while back when it was still just HTTP(S) available, push was not really possible... but there was a startup that built a instant messaging hub and a browser client - html and JavaScript - with the setup and the technology that could serve you very well... the startup go bought by google... of course... about and the domain disappeared... it was noob.com or something like that. Cannot find things on the Web anymore... The key function was that you could have this one instant messaging client and on the hub you would subscribe to all this plethora of instant messaging sites... like a federated instant messaging.

    How did it go:

    • The client / browser / your remote controller would send a GET to the hub server.
    • If an entry is waiting on the hub server, it would return immediately with the response.
    • If no entry is waiting, the request would eventually timeout, but triggered just the next one.

    This technology is against the initial idea of http protocol: request comes, gets served, and is stateless, resources are freed to serve next request / requestor. These long running request tied the resources - sessions - quite quickly: too many pending requests. That is when NIOB implemented: a pending request can be suspended in the the server, the thread is freed and handle other request, either incoming, or, when response is ready, pickup a suspended request and complete it. See http://tutorials.jenkov.com/java-nio/non­-blocking-server.html - which describes this... kind-a.

    Most application servers have this NIO technology implemented. At that time - quite a while ago - there was even a protocol developed and implemented in many language bindings. Using just two outbound http(s) connections provided the overall application with bidirectional push functionality.

    ...'found'/recalled the technologies: CometD, Bayeaux Protocol, (AJAX) Long Polling, Pub-Sub. Found also the CometD site and the salesforce developer site talking about.

    In a stealth org I had this running for an app I can understandably not talk about in detail... but what I can say is that two html / js apps in two browsers on different machines could talk to each other / control each other using the JavaScript language binding of the Bayeux protocol via a Java Web app using CometD implementation approach on jetty on a 'private server at a home' at a third location - securely and authenticated - after signing into the app server. To our surprise, the latency was in the range of 250...400 ms only... out of the box, no tuning applied. We also had a 'local hub' in mind that would either forward to the 'global hub' if the 'other party' is not local to the same 'local hub'. Today I would go for a nodeJS server and hub implementation in JavaScript rather than a jetty and java setup (assuming nodeJS Web (App) server offers NIO - looks like it is possible reading this (old but still younger) article on DZone from 11'.

    Today, as @Ollie mentions, Web sockets & MQTT is the way to go... but it was not (yet reliably) available then and may still today require more sophisticated setups.

    To make things simple, I would quench older - not picked up messages - on the server level rather than in the client level... messages arrived on the hub and not picked up within threshold just 'evaporate' connection is not present (goes absent for too long, no long poll request is waiting or showing up).

    After all, quite an interesting project...

    If the controller software is simple enough and https communication software still fits on a ESP8266 (see #232 How to secure our devices using SSL (ESP8266, ESP32, Tutorial) - Andreas Spiess, youtube

    ), it may still work. Espruino is then sadly out of the pic... To start prototyping: yes, Espruino-Wifi is a good platform. Could you also consider using BLE for communication between HW controlling devices and local hub? - then Espruino Puck/Pixl/MDBT42Q breakout board/module are viable options too with a local hub. And for the local hub: some RaspiPi... w/ Espruino or nodeJS. With a powerful enough platform the logic - FIFO/LIFO - can reside on it and the global hub works only as a "comm switch".

Actions