I am trying to connect multiple Nodemcu with Ubidots and finally add one master device that can read all the from other slave devices. Can I do it directly from Ubidots IoT Platform?
Yes, you can do it directly with Ubidots. I recommend you to manage your data using MQTT as a communication protocol. Check out Ubidots Docs for detailed info.
You have to use the publish example for the slave nodes, and from the master node, you must use the subscribe example to get the values from the different variables.
The code of this project can serve as a reference for you to subscribe to multiple variables at the same time.
Related
I'm using SignalR 1.0.4 and have a hub that returns a ChannelReader created from an observable by an extension.
A typescript client (also 1.0.4) is forced to connect using websockets only, and streams data from this channel fine.
Now I'm testing scale out using 2 instances of the hub, both using the same Redis connection. I'm emitting values from the channel's observable on both instances but the client only appears to be receiving data from the instance it is connected to. My conclusion is that the channel reader data is not broadcast to other channels via Redis.
I've tried to replicate this using the SignalRSamples by replicating the project and giving the copy different host IPs to emulate 2 load-balanced instances. I add the same Redis connection to both projects and start both up.
Regular websocket connections via the hubs.html have no problem broadcasting data across instances. The streaming.html doesn't replicate data for observable or channel reader.
Are channel readers meant to be used in this way, i.e. can they scale out?
ChannelReaders are meant to stream data down to the caller of the method. They don't participate in scale-out at all. Consider them the same as standard return values, SignalR just supports enumerating items off them over time. The programming model is very similar to how iterators work in C# (methods that use the yield keyword). If you want to broadcast messages to other clients, you should just use the Clients property on the Hub base class and send messages to those clients.
I am trying to do an IoT project where a node needs to receive some commands from cloud.
Previously, I made this with MQTT protocol. But searching about other protocols on internet I have found REST, which makes possible to communicate over HTTP. However I have seen that this protocol is more used for getting data (makeing a request to the node and receiving the data from it in the response).
I am very new with this protocol. So, I would like to know if it would also be possible to send commands to the node from the cloud, like in MQTT.
Thank you very much for your help.
The HTTP protocol and thus is based in a Request/Response model and using it for IoT device commands can have its drawbacks:
Your Devices will need to be accessible over the Internet and this can be a security compromise when you can have the Device with internet access using MQTT subscriptions but no incoming connections to it are allowed.
You will need to have some mechanisms for retrying and handling offline Devices in your cloud application sending the commands.
There is also more overhead on HTTP than MQTT given that MQTT has long lived connections. With HTTP you will waste more power on connecting and disconnection, also the network packets will be bigger than MQTT.
Can you use REST/HTTP for sending commands to Devices? Yes. Should you do it? Probably not, it all depends on your actual Device requirements and capabilities and why are you wanting to replace MQTT.
An IoT protocol that is similar to REST is CoAP. If you are thinking about using REST in the IoT context I recommend to have a look at it. If your nodes are always connected/reachable there is nothing that speaks against going in this direction. CoAP is a decentralized service protocol where each node might speak with another node.
MQTT is a publish/subscribe protocol with a central broker. As such your cloud could just send the commands to the broker and whenever the node connects to the broker it will receive the commands. So the node doesn't have to be online the whole time.
I have successfully Integrated TTN theThingsNetwork with my LoRaWAN Gateway. Also I am able to forward data between from Nodes to theThingsNetwork. Now I am looking for information to fetch data from TTN Thethingsnetwork to my own server. Any information will be appreciated.
Thanks in advance.
Regards,
Zaheen
First, let me welcome your on The Things Network !
To get your data to your own server, you have several possibilities:
The first one is to create a MQTT client running on your server to receive all your data in real-time. For this, you can use several SDKs provided by The Things Network at https://www.thethingsnetwork.org/docs/applications/sdks.html
The next way to do it is using integrations. In the upper-right corder of your application management console, you should see an "Integration" tab.
Using this tab, you can create two different types of integrations:
The first type is the "HTTP integration". Using this one, all received messages for your application will be forwarded to the url provided in the integration configuration. A complete documentation is available at https://www.thethingsnetwork.org/docs/applications/http/
The second type is the "Storage integration". Using this one, all your received messages are stored in a database for 7 days ans are query-able via REST. A complete documentation is available at https://www.thethingsnetwork.org/docs/applications/http/ https://www.thethingsnetwork.org/docs/applications/storage/
I have one question regarding sending stream to TV using wowza.
I need to send multiple streams running at same time to TV station with using one link
Basically question is that, I have multiple streams with different name and when i need to send to TV it convert to one unique name on run-time.
Is this possible ? if yes please explain bit more..
thanks in advance
By sending to "TV" you mean leveraging Push Publish to send to an external CDN or Wowza Server, then you can specify the outbound stream name within the Push Publish mapping by setting the "streamName" parameter. You could also remap the inbound published stream name via the approach found here.
Otherwise, if you are referring to requests made for a particular stream on your given Wowza Instance (vs pushing outbound), then you could leverage the Stream Name Alias module of which you could map any stream name to another.
Thanks,
Matt
I am developing an iPhone application that allows to basically click through a series of actions. These series are predefined and synced with a common configuration server.
That app might be running on multiple devices at the same time. All devices are assumed to have the same series of actions defined on them. All devices are considered equal, there is not a server and multiple clients or something like that.
(Only) one of these devices is used by a person at any given time, it is however possible that the person switches to a different device at any given time. All "passive" devices need to be synchronized with the active one, so that they display the same action.
The whole thing should happen as automatically as possible. No selection of devices, configuration, all devices in the same network take part in the same series of actions.
One additional requirement is that a device could join during a presentation (a series of actions) and needs to jump to the currently active action.
Right now, I see two options to implement the networking/communication part of that:
Bonjour. I have implemented a working prototype that can automatically connect with one (1) other device in the network and communicate with that. I am not sure at this point how much additional work the "multiple devices" requirement is. Would I have to open a set of connections for every device and manually send the sync events to all of them? Is there a better way or does bonjour provide anything to help me with that? What does Bonjour provide given that I want to communicate with every device in the network anyway?
Multicast with AsyncUdpSocket. Simply define a port and send multicast sync events out to that port. I guess the main issue compared to using bonjour with tcp would be that the connection is not safe and packets could be lost. This is however in a private, protected wlan network with low traffic if that would really be an issue. Are there other disadvantages that I'm not seeing? Because that sounds like a relatively easy option at this point...
Which one would you suggest? Or is there another, better alternative that I'm not thinking of?
You should check out GameKit (built in to iOS)--they have a lot of the machinery you need in a convenient package. You can easily discover peers on the network and easily send data back for forth between clients (broadcast or peer to peer)
In my experience Bonjour is perfect for what you want. There's an excellent tutorial with associated source code: Chatty that can be easily modified to suit your purposes.
I hobbled together a distributed message bus for the iphone (no centralized server) that would work great for this. It should be noted that the UI guy made a mess of the code, so thar' be dragons there: https://code.google.com/p/iphonebusmiddleware/
The basic idea is to use bonjour to form a network with leader election. The leader becomes the hub through which all the slaves subscribe to topics of interest. Then any message sent to a given topic is delivered to every node subscribed to said topic. A master disconnection simple means restarting the leader election process.