Timeline for PIGPIO stream pwm data over websockets with nodejs. GPIO
Current License: CC BY-SA 3.0
19 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 17, 2018 at 19:02 | history | edited | CommunityBot |
replaced http://abyz.co.uk/ with http://abyz.me.uk/
|
|
| Jun 10, 2015 at 22:01 | comment | added | goldilocks♦ | Just to make sure there is no further confusion: I'm not saying you replace the websocket with something else. You have the websocket application, which on the "front" has a TCP socket to the outside world (a websocket styled connection to your phone). On the "back", you set up another socket, a connection to pigpio, and you pass the information through that way. | |
| Jun 10, 2015 at 21:57 | comment | added | goldilocks♦ | In that case it sounds like you don't even have to worry about the async event handling stuff -- you can just block and do your transfer exactly the same as you are already doing with writing to a pipe, except it's a socket. Note that a websocket is a TCP socket so again, whatever node facility you are using, that part of the API must be available. | |
| Jun 10, 2015 at 20:51 | comment | added | cocco | i use also nodejs as webserver that outputs the html file to drive everything... loaded once it's stored in the device(localstorage & cache.manifest) and so i don't need to bother about a webserver(every other type of server).. the app also works if the webserver is offline, the websocket server needs to be online. most of the real cpu/gpu(css 3d) intensive work is done with the client. | |
| Jun 10, 2015 at 20:39 | comment | added | goldilocks♦ |
"w/" = with, "w/o" = without. For hopefully obvious reasons, node includes a TCP socket implementation, and you can use that to communicate with pigpio from the server, not the client: I don't mean you should replace your websocket, I mean you do this on the back the same as you would with a local database. You're just replacing the /dev/whatever stuff with socket stuff. This is slightly more complicated in that it probably requires callbacks since node is asynchronous, but you're already familiar with how to do that if you've been using it at all.
|
|
| Jun 10, 2015 at 18:29 | comment | added | cocco | @goldilocks "w/ node" means without? in that case i need to know how can i implements sockets with javascript? now everyone with a smart device can control this raspberry. no apps or anything else needed just a browser. Sockets != websockets and so i can't just connect a socket server without an external language that makes this possible.Each device would need to have a custom app that supports sockets. | |
| Jun 10, 2015 at 18:14 | comment | added | cocco | btw i think you can't seek the /dev/pigpio stream. joan wrote the pigpio code. he knows. | |
| Jun 10, 2015 at 18:13 | comment | added | cocco | but the client (html&js) needs to talk with nodejs js has a native websocket api.. does it also have a native socket api? | |
| Jun 10, 2015 at 18:10 | comment | added | goldilocks♦ | I think the socket will actually be a more appropriate fit w/ node. High level file interfaces can make assumptions that aren't always appropriate to things that aren't literally static, stored sequences of bytes (which may explain your "seek error" problem). | |
| Jun 10, 2015 at 18:03 | comment | added | cocco | btw i open the stream and it remains open. closing it everytime would slower the nodejs. atm i'm totally using it only as passtrough. i open the server(websocket) and open the stream.Every incoming data is then directly pushed to the pipe. | |
| Jun 10, 2015 at 17:56 | comment | added | cocco | it looks like that at the nodejs side, writing it like i do, there is now way to flush. what problems could come up? | |
| Jun 10, 2015 at 17:43 | comment | added | joan | Yes, but you compromise the update rate. The default resolution at 800Hz is 250 (It's scaled to 255). If you drop the update rate to 400Hz the resolution becomes 500, if you drop the update rate to 200Hz the resolution becomes 1000. Alternatively you could boost the sample rate when the pigpio daemon is started. See this table. You are correct about the socket, it probably is simplest to use a pipe. | |
| Jun 10, 2015 at 17:36 | comment | added | cocco | but using sockets you need a special devices that is able to control that specific socket... and it does not work over http using a simple html page right? using websockets i just need to open a "modern" browser and point it to the raspberry... am i correct? | |
| Jun 10, 2015 at 17:34 | comment | added | cocco | the only thing i'm worring about now is the resolution (it's already enough).. 8bit 255 ... is there a way to increase that to 1024? on servoblaster i used us (microseconds) | |
| Jun 10, 2015 at 17:34 | comment | added | joan | I've never actually done any tests on relative performance between the pipe and socket interfaces. I tend to use the socket interface as it naturally works over a network. Pipes can only be read/written by software running on the Pi. | |
| Jun 10, 2015 at 17:24 | comment | added | cocco | You also this that is a good/fast way to write the info? or is there a faster way to send the pwm data to your pigpio? | |
| Jun 10, 2015 at 17:23 | vote | accept | cocco | ||
| Jun 10, 2015 at 17:23 | comment | added | cocco | omg i forgot the new line!! i'm an idiot. yeah 3h for a stupid error like this thx joan ... btw very nice lib!!!! | |
| Jun 10, 2015 at 17:19 | history | answered | joan | CC BY-SA 3.0 |