I have started to work with OpenThread with a Nordic DK.
I am working with the BLE/Thread coap example that I modified in order to be a FTD instead of a MTD. Also, on one of my devices, the CoAP is configured as a server.
I figured out that when I pushed the button nRF52840 DK board programmed as a CoAP server, the light of the other board changes which means that the otCoapSendRequest function works.
Isn't it supposed to only works on a client device ?
Is it a normal or just a small bug in the OpenThread function ?
I can't speak for OpenThread in particular, but it is common in CoAP that server functions are enabled in addition to client functions rather switching between client and server mode – so it's not unexpected that client features still work even though you enabled server features.
This is because CoAP is designed to have much code shared between client and server. The Web of Things architecture calls the resulting client-server nodes "servients" (server-clients).
Thanks for your answer.
I dug into the Nordic Code and found out that the CoAP init function creats services if the server mode is enable.
In my code I switch from server to client on a randomly elected main device and this switch seems not to remove the services, I guess this combine with what you said explains what I have.
Related
I would like to talk to a custom piece of hardware via my web application using WebUSB
The hardware is already able to communicate to a python script running on a laptop via USB
Now I have 2 questions and I hope you can help me :)
Does the hardware need to implement anything WebUSB specific? Or is the USB communication that is already implemented enough?
Is WebUSB ready for production? This application will be used by customers to talk to machines like excavators.
The whole application (talking to machines) already works via internet - we just need to implement the USB communication to handle the case that the user doesn't have a working internet connection.
best,
Kev
Does the hardware need to implement anything WebUSB specific? Or is the USB communication that is already implemented enough?
It is enough.
Is WebUSB ready for production? This application will be used by customers to talk to machines like excavators.
The Chrome team takes the decision to make a Web API available to developers very seriously and is committed to supporting these APIs for the long term. The draft status of the WebUSB API should not be taken as a reflection of the Chrome team commitment to this work. It is a necessary effect of how the web standardization process works.
The WebUSB API has been available for quite some time and is considered stable. While we have been making steady investments in the implementation of the API there are no changes to the developer-facing interface planned.
Hi we have an IOT project that has a running website + android app , that is made on Node.js server and uses the HTTP protocol with REST API's to communicate with embedded device CC3200 from Texas Instruments .
The project controls heating beds by sending messages from web or mobile to CC3200 which is our control box that sends the commands to the heating beds .
Problems :
We require port-forwarding on certain ports , we need to get rid of it
CC3200 when post changes to the web , changes cannot be seen unless the page is refreshed .
I researched and found that there are two possible solutions , either to use IO.js or switch to MQTT . But at this final stage of the project both the solutions seem like starting from a beginning .
Any help on this will be appreciated .
PS: Port-forwarding is more of a big issue
Most solutions typically relies on a long-lasting connection initiated by the embedded device to the outside server in order to get rid of port forwarding issues. As you cited it, MQTT allows you to do just that, but so does Long-polling HTTP, or even Websockets.
Using one of the above does not necessarily mean starting from the beginning, but certainly requires some additional work to get this logic implemented on the embedded device on the first hand, and setup a publicly available secure message broker (e.g MQTT) on the other.
Another solution, would be to use UPnP IGD to dynamically add port-forwarding entries on the home gateway (if it is supported), or use STUN techniques. Note however that this solution will expose the device to the outside world, publicly, so you might want to pay attention to the security aspects this implies.
See also :
UDP Hole Punching
STUN, TURN & ICE for NAT Traversal
does anyone know of a hardware platform that is appropriate to use in prototyping a device that has the ambition to become WWN? I have looked at Proton/Spark-Core, but is there something out there that may be more appropriate/compatible with the Nest-API? Thanks.
Basically anything that can run a web service. All you'll need to do is make an HTTP GET and PUT over HTTPS. More advanced things like Firebase and REST Streaming can still be easily done with a Raspberry Pi. I'm pretty sure an Arduino with a mini-web server can handle GETS and PUTS.
I have an Arduino board in a location, and a webserver.
I also have a website that is supposed to control the Arduino. What technique would allow users to take control of the Arduino board with the least amount of latency?
I have Node.js, socketserver, Jabber in mind to experiment with, but is this the right direction?
You should have a look at Socket.IO for implementing WebSockets on server- and client-side.
There's a great project called duino for accessing Arduino with Node.js, you "only" have to pipe all communication through WebSockets.
Update: In the meantime I have published a framework for sending commands to an Arduino with Node.JS, JavaScript and WebSockets. Make sure to have a look at Noduino!
I had good luck using node-serialport to talk to the Arduino. Using the serial port results in very low latency, and I used it to build a photobooth. The code is on GitHub if you want to check it out, though it's very poorly organized as I was rushing to get this done for my wedding and well... corners were cut.
I'm finding a way to realtime messaging in iPhone SDK. iPhone Safari doesn't support Web socket. Apple push notification is working only on application is close. I want to make like chat program with real time. There is other way except web socket ?
It's likely that the next version of iOS (4.2) will add WebSockets support. iOS 4.2 should be out this month.
You might looked at Socket.IO if you control the server side too. Socket.IO is a JavaScript library for the client and server that uses the best communication transport that both ends support starting with native WebSockets, then a Flash based WebSockets fallback, then various long-poll/COMET options. The API on client and server sides is very much like the normal WebSockets API regardless of which underlying transport is used. It would allow you to use the WebSockets protocol when available and fall back to something that still works when you don't have WebSockets (without requiring you to use a different API).
You can do some of the traditional "comet" tricks like long-polling or a forever iframe, however I'm not sure any of those are as concise as WebSockets.
If you're looking for a paired client / server side library, I would look at Socket.IO.