I am wondering what is suitable for my case, using espeasy or Tasmota. I know espeasy is using http requests and Tasmota is using mqtt.
I want to control my sonoff devices by a raspberry pi that is acting as a home automation hub, and it in turn send updates and receives commands from AWSIoT platform. For interacting with AWSIoT platform, it uses mqtt.
What are the pros and cons of using either? and will it cause problems if I control several sonoff devices with http, while using mqtt for AWSIoT? or better use mqtt for all AWSIoT and sonoff?
I am not an expert on the topic but have tried a few things and got some insight for you on why to prefer MQTT over HTTP.
Security. Remember that the 'S' in IOT stands for security. Joking aside. I have not seen an option for encryption (HTTPS) of the HTTP-traffic for tasmota. (May the internet correct me if I am wrong) So choosing HTTP means your user/password (which are not a requirement but should totally be used) are transfered via URL query parameters as plain text. MQTT has built-in mechanisms for encrypting the traffic. I haven't been able to get that working in my network but I'm trying.
Flexibility/Reliability. With MQTT/Tasmota you have the ability to implement automations that do not rely on your home automation hub by having your devices publish MQTT-messages directly to each other for interaction. For example if you would like to implement an emergency off button that turns multiple devices off you do not want that to rely on your home automation server. Doing this with HTTP 'could' be done too but requires all users/passwords of all the devices to reside not only in your home automation hub but also on other single devices.
Networking. Adding new devices to your hub should be as easy as possible. In matters of HTTP your home automation hub has to know how to find your devices via IP-addresses or domain names since it has to resolve a URL. When using MQTT you just connect your tasmota devices to your broker and use their topic in the home automation hub. The devices do not even need to have a static IP or reachable domain name of mDNS name of any sort. That's in an essence what makes pub/sub for IOT so interesting in the first place.
Existing support. Before building your own home automation solution be sure to check out home assistant (my favorite) or any of the other home automation solutions if they fit your need. Do not reinvent the wheel. A tipp for home assistant: Do not use MQTT auto discovery in combination with tasmota. This is the only thing that has not worked out for me. Manually registering devices works reliably.
Hope that helps. If you still prefer HTTP checkout the app "Tasmota control".
Which tools/servers etc would be needed? Is there any articles or something that I could read along and follow to help me create the functionality?
Let's assume that your chat application is a web app. You could integrate it with asterisk through a library suporting sip (e.g. sip.js) working on top of WebRTC. In WebRTC, the sources and sinks of media streams come or go to audio (or video) tags that have attributes as muted (see HTML Audio/Video DOM muted Property) than can be managed by the app to simulate PTT. The PTT can be implemented with a button in the app, with a keystroke or even with an USB HID device depending on how much do you enjoy struggling with external access to browsers (I certainly do).
There are alternatives involving some kind of third party control (AMI, for example), that would take advantage that ConfBridge can be controlled to mute participants on the fly. It all depends on the specific requirements.
You can't do real push-to-talk using asterisk/sip.
Just becuase sip connect sequence take 0.5-1second usually.
Best option is use your own custom app which will maintain sip session(send sip ping every few sec) upto X(for example 1minute) second after last message, not send rtp if user not pressed key(but you still need send keapalive rtp to maintain NAT).
I was following THIS tutorial in order to implement video calling using WebRTC. The example allows people of the same group to communicate using video or audio and it works well. I was wondering if you could Video call people who are on different pages of the same website without having to be on the specific 'video call page' only?
What is the way to allow incoming calls even when you are not joined in a group? I believe it must be a group request (Sending a request to join from Person A to Person B). Is this possible using WebRTC?
WebRtc is not based on "who is connected to what page".
The connections only happen through your signalling server logic. This means that any webrtc peerconnection can connect to anyother peerconnection as long as your signalling server relays the connection startup logic(SDPs and Ice candidates).
The webpage is only a way to display the media that you have, the javascript you wrote will run on any page you want.
I am writing a chat application in QML/C++. I have already implemented an option to chat locally (with people in the same network) and I am currently working in implementing a bluetooth chat option.
However, one early user of my application suggested me to implement an ad-hoc based chat option that would communicate each device directly (without the need of a router, in other words, peer-to-peer). This feature would be very useful if the user(s) are located in a place without an internet access point, say a music festival or in an event.
My application uses the Qt framework and it has the necessary tools for me to implement this feature, however, I am a hobbyist programmer and I don't have a lot experience dealing with network connections.
Do you know any way to implement this ad-hoc, peer-to-peer feature? (or know any helpful websites/links).
Thanks in advance,
Alex.
You can use TCP or UDP protocol for your chat application.
TCP = connected protocol
UDP = "broadcast" protocol, more speed
Example here :
http://qt-project.org/doc/qt-5.0/qtnetwork/network-chat.html
Or here : http://qt-project.org/doc/qt-5.0/qtnetwork/examples-network.html
Yekmen
is there a way for a server to push some data to a client, wirelessly and seamlessly, which may be Windows(Phone), iPhone, Mac, or Android device, without any OS integration?
If so, what's the best design pattern to do this, and what are the best technologies to go about this?
Push technology is simply a methodology of the server initiating the transfer of data, rather than the client asking the server for it.
Apple makes push technology relatively easy to use by providing such functionality built-in on the OS. As well as Android through the Google Cloud Messaging for Android. Windows, however, does not.
Apple push notifications and Google's messaging for Android is seemingly magical and/or functionality that the OS needs to handle; however, this isn't necessarily the case. The advantage of having it "integrated" in the OS, is the same as having a framework handle the functionality for you.
Speaking in technical terms, push technology is a long-lived connection from the client to the server that accepts messages. These messages would be considered pushed messages, since the client did not make an individual request for them.
The main thing to keep in mind when implementing push technology yourself, is that the client is in charge of keeping that long-lived connection alive as much as possible. Because client IP addresses can change between disconnects, servers are not guaranteed that a client's address will be persistent across disconnects. Moreover, clients can be connected from behind a firewall, making it impossible for a server to reach the client.
For comparison, pull technology is the more traditional process of a client connecting to a server and requesting data.
Your best bet for Apple iOS will be using their push notification service.
For Android devices you should use the Google Cloud Messaging for Android. Alternatively, you can create your own background service to handle the messaging; here's a guide.
For Windows (desktop at least), you will have to create your own service to perform such duty. Here's an MSDN guide explaining how to create a Windows Service using Visual Studio (VB and C#). There might be frameworks already built that handle such messaging on Windows, however, I don't know of any.
Use WebSocket (with or without socket.io).
In the future, you could use WebRTC.
With Websockets, the setup is really simple. The client (a user agent, like a browser or a WebView) connects to the Websocket server, over http(s) (less problems with firewalls) and that's it. There's a bidirectional socket with an event-based API.
If by "OS integration" you mean "write special code for each platform" then the answer is no.
As you mentioned, you would like file system access, and background processing. That combination is not available in a cross-platform way at this moment.
If by "OS integration" you meant "without having to wait for apple/google/ms to provide the ability" then the answer is yes/maybe.
All the popular platforms have Push notifications and background processing support, as long as you code it the way each particular platform expects it.
But file system access will be limited to what restrictions the platform places on you. For instance in ios and win8(phone) there is no wy to write or read a file outside of your own apps private file structure. For security reasons, you cannot access the file system of other apps.
UPDATE:
The general pattern here is to release an app for every platform you want to support.
The app will register itself with its respective platform's push notification service.
You will write generic server side code to accept the data you want to push to all your client devices. Then you will invoke the respective push API's for each platform you support, causing the client devices to wake up and trigger the app that you provided to respond.
When the app opens, you get the app to contact your server and download the full data "the push notification being just the wakeup call for your app"
This way you can easily tell how which of your devices have received the data.
Each platform specific app must save the data to its own local storage and provide a way for the data to be shared via the methods supported by its respective platform.
On IOS it can be as simple as supporting the "Open In.." paradigm.
On W8Phone, you'll have to publish the data via one of the available "sharing contracts"
And so forth for every platform you want to support.
This is the general pattern at the moment. There are some caveats. On IOS, the app will nt automatically start when a push notification is received. This means your app will only download the whole of the data when the app is opened by the user.
A mobile app also cannot generally run indefinitely in the background. This means that once the app is started, you have a limited window for push notifications to be automatically processed by your app. After the allowed "background time". The app will close and any push notifications beep on the device, but wont open the app until the user taps on one of the notifications or opens the app directly.
Technically you could use XMPP Libraries, it is meant for implementing chat system (msn, gtalk, facebook chat, etc...) but this could work well as a push message system because it is opensource and well built to handle all the cases you never thought of. Also you could host your own server and send push message that way...
Why not use a webservice? In my previous project I used webservice to deliver data from mysql database. The webservice I used was nusoap. On the client side I used kSoap library for Android. Hope this helps.
if you want to receive and send real time communication between a server and client (irrespective of the device or OS), i would highly recommend you use XMPP technology because it is designed for the sort of things you're asking for.
The Extensible Messaging and Presence Protocol (XMPP) is an application profile of the Extensible Markup Language [XML] that enables the near-real-time exchange of structured yet extensible data between any two or more network entities. The core features of XMPP defined in [XMPP‑CORE] provide the building blocks for many types of near-real-time applications, which can be layered on top of the core by sending application-specific data qualified by particular XML namespaces.
http://xmpp.org/rfcs/rfc6121.html#intro - that is the latest RFC which will give you a good starting point.