Any help appreciated.
At the moment, it doesn't do WebSockets - but you could still push data with the HTTP client/server.
I'm actually in the process of refactoring the HTTP server/network code in the hope that CC3000/WizNet/others can coexist in one binary. Once that's done, implementing WebSockets should be trivial.
That would be awesome! I know it's probably not a priority, but I think it will make an awesome way of communicating with/from the Espruino given that it is becoming a widely used standard.
I look forward to seeing how the HTTP refactoring goes, and would be happy to give implementing a WebSocket ago once it is (maybe with a few pointers first :))
Very nice Gordon !
Befor implementing websockets, please implement basic socket connections first ;-).
First let me say the outlook to get websocket support on the espruino is excellent. Also I recently got in touch with SSE - Server Sent Events, which looks like a cool and easy implementation if you just need to send events from the server.
Essentially the client, e.g. espruino connects to a socket and the server keeps the connection open. A new message is simply seperated via \n and carriage return (or so, details in the spec, but really easy).
SSE or WebSockets - I see the espruino being the initiating "client" in these scenarios. It just seems to be the easier option to connect out than trying to expose the local IP/server to the outside. Is this common thinking or is there a better option that I am missing?
Also, unfortunately WS/SSE sometimes fail - so an onError handler with the option to recreate the connection could make the connection really stable. Can this be done? I know there is no exception handling, is this required for a onError callback for a websocket? Or is this handled in your integration code and thus no JS Exception handling would be required?
SSE is "http" based. Take a look at this implementation of SSE:
I think SSE could be implemented on top of the existing HTTP implementation we have allready.
For WebSockets and other protocols we need basic "net" (socket) support.
There's no reason that there can't be an onError handler added. Overall I think it's quite promising - it's just finding time ;)
+1 for WebSockets!
This node.js ws repo might be helpful: github.com/einaros/ws
Hi, what's the status on this?
Socket support is in (see espruino.com/Reference ), but not websockets afaik.
The only slightly tricky thing needed is the hash algorithm for setting up a connection, but that shouldn't be hard. Espruino can be natively compiled pretty easily for Linux/Pi/Mac, and WebSocket support could be developed on there, which might make it a little quicker.
Thanks for your answers.
Not sure I would have enough time and skill for that. But it would definitely be a great tool.
So basically: +1!
And good luck for your other stuff, I hope it concerns Espruino Pico :)
Guys, I've managed to write a websocket module for Espruino, you can try it out here:
Please bare in mind it is still in an early stage, please let me know if you are facing any issues
@sameh.hady thank you for this
@sameh.hady You ROCK!! I can't wait to try this out.
Thx guys, looking forward to try it out and give me your feedback
This is incredible, excellent work.
Nice work! Definitely something I've been hanging out for.
Can this be used on the ESP8266 as the espruino. Like the ported version?
@Ducky yes, actually my tests were only done on ESP8266, i didn't test it on any other board.
oh sweet, excellent work.
Just to add, there's a bug open for a websocket server. It'd be much better done inside Espruino itself, because then you could use the existing HTTP server to serve up webpages and also to handle WebSockets.
@Gordon if we are going to run the websocket server in Espruino we will loose the the main purpose of websockets which is cloud messaging. In that case you will never be able to send messages to Espruino unless you are in same network or having a static IP address.
Normally the socket server should run on a public server. Espruino & webpage or mobile app should act as a client connecting to that server as we already know it's IP. In that case you can control Espruino from anywhere.
What would be neat is to introduce new functionality to Espruino which is Cloud controlling.
For an instance you can create new subdomain ex: cloud.espruino.com and let users register there. This will be a private cloud server for all espruino users to connect and control their modules online.
You can also offer sweet dashboard to see all your nodes and statistics about them.
People who were pushing for WebSockets before wanted them for realtime control. So in that case they wanted Espruino to serve up a webpage with some stuff on, which then communicated with Espruino via Websockets. For that you'd need a server inside Espruino.
My message above wasn't getting at your client implementation, that's great! - it was just because @JumJum had been looking at creating a Websocket server in JS, and I wanted to point out to anyone else that there was already a bit of the work started.
It's a good thought about the public server. I'd be a bit worried about doing it right now, but when TLS support gets put in I'll definitely think about it (although it's all more development time ;)
Having said that, if I control the server and the client, Is there a reason I should use Websockets as opposed to 'normal' sockets?
Don't worry about formatting, just type in the text and we'll take care of making sense of it. We will auto-convert links, and if you put asterisks around words we will make them bold.
For a full reference visit the Markdown syntax.
© Espruino, powered by microcosm.
Report a problem