I have a RaspberryPi connected to my home network via WiFi with a dynamic ip address. I then have my iPhone connected to the same network also via WiFi. The Pi has a lightweight c++ HTTP server running on it that can execute commands. I now want to write an Objective-C app that can find the Pi on the network, regardless of it's ip address, and send it commands. So, Universal Plug and Play seems like the logical solution - but everything I find on Google is dealing with Media players and streaming audio/video content.
I just want the Pi to somehow simply broadcast on my network - "Hey, I'm RasberryPi and my IP Address is 192.168.0.5!".
Can somebody please suggest a package or solution to this problem? Thanks!
For the RPi side I would suggest GUPnP as long as you can fulfill the dependency requirements. It's a very modular framework so you don't need to load or use any of the multimedia related things if you don't need them. It's based on glib and libsoup and allows you to fairly easily define and implement your own UPnP services. Take a look at the BinaryLight example: It implements a BinaryLight Device that contains a SwitchPower service with several methods and two state variables (properties). You should be able to hit the ground running if you start with that. There's documentation on how to write a server.
The components you are going to need/want:
libgssdp, handles discovery, used by gupnp
libgupnp, the actual upnp implementation, used by your app
the dependencies (glib, gio, gmodule, libsoup, libxml)
Also possibly for testing (this on a desktop linux machine since it requires gtk):
gupnp-tools, contains gupnp-universal-cp
EDIT: If you really don't want to implement any UPnP functionality, it's possible you could just use GSSDP for the IP discovery. This could be very simple: see test-publish example.
Related
I am starting ROS on Ubuntu 20 on Raspberry PI with setting ROS_HOSTNAME to $(hostname).local and ROS_MASTER_URI to http://$(hostname):11311.
The problem is that if I am connected to WiFi and then that connection fails (for example if WiFi goes out of range), then the robot stops working correctly.
I was thinking that a possible solution could be to create a new network interface or a VLAN and start ROS on that network and then bridge that new network to wlan interface. This would make the network that the ROS is connected to independent from wlan interface, but it would still have access to network if wlan would be online. I would also like to keep the possibility to connect to robot's ROS through another device on the wlan network.
I am asking here for help because I don't have enough networking knowledge to make this work. So any guidelines would be appreciated. If there is another better approach to solving this problem, please let me know.
I suggest using ros_bridge for communication with the robot. It is often used if you have a web interface for your robot and you need to visualize some data from the robot's backend on the web. Or even send a command to the robot.
The counterpart to this node is the roslibjs library. You can find it here
For more info, you can check Robot Web Tools, a collection of tools for web-based robot apps.
However, maybe you are not interested in web apps; you can still use ros_bridge with roslibpy which is python implementation of rosbridge protocol. It is the same as roslibjs, but this uses python instead of javascript.
You can easily create a python app which will use roslibpy to subscribe or publish to topics or call services.
This approach is better because you will encapsulate your robotic backend, and you can control what is visible to the outside world with params for the ros_bridge node. You can also handle better reconnects if your robot lost wifi connection.
Still, you can use exposed ROS_MASTER_URI for rviz and debug proposes, but I wouldn't try to use it for controlling the robot because the connection between nodes won't be recreated if you lose wifi connection.
In my work, we used ros_bridge for some time in production AMR, and I have to say that it wasn't as robust as I thought initially. For example, there were issues when the robot changed the wifi access points, and caching messages didn't behave according to the documentation. For the web, we still use it but to control a fleet of mobile robots, we had to abandon it, and we developed our solution based on rabbitmq.
But I guess that if you are using Raspberry Pi, then it is not a production robot, and therefore I think you should be OK with ros_bridge.
node-red-contrib-homekit is a slick way to create virtual HomeKit devices in Node-RED, providing a bridge to non-HomeKit-aware hardware.
When it is time for my Node-RED flows to talk to real HomeKit devices, however, it seems to get messy.
To control a HomeKit device (thermostat, outlet, bulb, occupancy sensor, etc.) from a Node-RED flow, the most elegant solution I know of is to install Homebridge and something like homebridge-mqtt alongside Node-RED, which feels to me like a big, awkward hammer.
I feel like I'm missing something--is there a more direct approach? Or am I doing it in an advisable way?
As far as I know, there is no way to talk from Node-RED to HomeKit enabled devices using the HomeKit protocol. Apple only publish the specs for client devices and services, but the HomeKit server, and therefore UI, can only be iOS device. You can think of HomeKit as the Apple alternative to Node-RED. And the control can only be one way - from Homekit to Node-RED. You can make the data flow both ways though. For instance you can create virtual HomeKit switch in Node-RED, that the Home app can control using automation (like turning on when you're home). Thus you can have binary communication between them.
The protocol actually specifies a set of predefined accessories with their options and capabilities, and each manufacturer should provide API for the selected accessory. One physical device can have multiple virtual accessories - like temp and humidity sensors, that are shown as two items in Home app, but might be one actual device.
You need to use your iPhone/iPad to add and control the bridge/accessories, that you can create in Node-RED or are licensed HomeKit devices. But they are not able to talk to each other using that protocol. You'd have to find alternative way for doing this by looking for another API by the manufacturer. For instance Hue is certified as HomeKit and you can add it to your Home app directly, but if you want to control it with Node-RED you'd need their other API as the HomeKit server is proprietary.
Also for Node-RED use the updated node-red-contrib-homekit-bridged that can simplify your management.
I’m in the process of changing my setup from the node-red Homekit node to a separate Homebridge with the MQTT plugin myself. Not only because it is more elegant but also more flexible HomeKit-wise, provides a “separation of concerns” between processes running, and also let’s me just add one bridge to Home app.
There’s also a websocket plugin for Homebridge which also plays nice with node-red but as I have a mosquitto MQTT broker running anyway I might as well use the “language of IoT”.
I am in the process of connecting Homekit related devices and services with Node-RED using Homebridge. Both Homebridge and Node-RED can be installed on the same machine (a Pi).
There are several plugins available to connect Homebridge with Node-RED and maybe you can create a flow that then controls your devices for which you also have to find a plugin in Node-RED. It may be a bit over engineered as there are tons of plugins available for Homebridge directly but using Node-RED is much more fun. The MQTT way is also a good start but I didn't want to mess with protocols and stuff.
I'm a seasoned developer who is jumping into to OpenThread for home automation specifically for Nest products. I'm more interested in exploring the possibility of communicating with Nest devices through local protocols via border routers, local link and local mesh presence of FTD's & MTD's. I'm not interested if it can be avoided to use the Nest API through the cloud and user accounts.
I've started with the Nest Learning Thermostat and I'm prototyping on a Raspberry Pi 3 and have successfully built the Open Thread Posix platform and other steps on their git repo here: https://github.com/openthread/openthread
I am able to ping between 2 platform NCP nodes via ot-cli-ftd, and some, but not all the necessary wpantund(?) services are running.
The above steps describe the direction I'm going, but I'm not sure it's the best or correct way to do so, but makes sense based on what I've read so far.
Since the Nest Learning Thermostat already attaches to your local wifi network via tcp/ip, I'm trying to determine if the thermostat has a built in border router, routing 802.15.4 traffic to wifi? Does anyone know? I've been able to connect my thermostat to my home wifi network, but I haven't found any examples of communicating with it the way I am going.
If the thermostat doesn't have a border router, or the tcp/ip connection is proprietary and not accessible to makers like me, then do I need to get an 802.15.4 platform to communicate with Nest devices?
Thanks for any help you can give.
- Doug
Today, the Nest Learning Thermostat makes use of Thread technology primarily for controlling Nest HeatLink products in Europe. It does not expose any APIs for control or introspection over Thread right now. If you want to interact with the Thermostat, you'll need to use the Works with Nest (cloud) APIs.
Thread (and OpenThread which implements it) provides only a network layer, but for meaningful interactions, you'll need an application layer on top of it. Nest products use the Weave protocol suite for this purpose. Nest is not quite ready to provide full third-party interactions directly to their products quite yet, but you can begin exploring Weave technology over at http://openweave.io/ -- watch that space for more to come.
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
I am Developing a Java ME Application. Here I am using WiFi Connection. Now My Question is how to get a particular WiFi Connections name using Java ME Code ?
My Requirement is for Nokia E5 Device only.
After doing much research work I found that this is not possible in Java ME Technology to fetch the WiFi Connection's Name.
However Similar Library would be com.nokia.multisim.networkid which returns Network ID and Network Short Name.
I Dont Think so it is 100% possible in J2ME and even though if it has worked and there is no guarantee that it will work on all J2ME devices which has Wifi connectivity.
most appropriate answer i have found , please go through it once.
" Much as I hate to put you through all that grief and then not have a simple answer, I don't have a simple answer.
The reason for that is because Java's networking model is based on TCP/IP, and the TCP/IP architecture is based on the idea that applications will neither know nor care about the hardware details of networking. A typical mobile device may contain several different network interfaces (WiFi, Bluetooth, Infrared, USB cable, and so forth), but when an app wants to contact another network node, the app doesn't know which of these interfaces is actually being used. And in fact, if the OS wants to do so, it can use more than one (in parallel) and/or switch interfaces in and out, based on routing criteria such as best measured data rates. Rather like how cell phones route phone calls.
So basic Java/JME won't know anything about WiFi.
However, there is an extension, specified as JSR 309 (http://jsp.org) that looks like it may help. It supports learning about and controlling the network interfaces themselves. The problem is that not all devices will implement this extension, so it will depend on what device(s) you are supporting. "