I want to start an IoT project with multiple machines (i.e., Raspberry Pis) in different locations (i.e., throughout a city or several cities).
Each machine should be able to send data to a back-end (ex., alive ping, sensor read-out updates, etc.) or receive orders from a back-end and send back response.
I don't want to start from scratch (can't use Amazon or Azure IoT service) - is there a framework that would do this (can register to the service and allow me to check which machines are up/down, send them messages, etc.)? I would prefer open-source possibilities, if possible.
For seeing what's going on with all those devices, and notification of problems, and automating any processes, then DevicePilot is worth a look. It's not an IoT platform though (there are plenty of those).
Cumulocity offers a complete Software-as-a-service to do that.
Raspberry Pi integration is described here:
http://www.cumulocity.com/guides/devices/raspberry-pi/ (Java Agent)
or here:
http://www.cumulocity.com/guides/devices/janztec/ (C++ Agent)
The agents are open source (under https://bitbucket.org/m2m/ ), the server-side platform is not open source (except examples). But you can get a free trial (see http://www.cumulocity.com/ ).
On
It would work like that: upon start, raspberry would register to the service, once done, the service allow me to check which machines are up / down, send them messages etc.
This is supported out of the box without programming. Please see links above.
Stefan (working for Cumulocity)
Related
Need to understand something related to Citrix XenApp and XenDesktop.
If I install a software (e.g. Paint.NET) on Citrix Server and publish it via XenApp and XenDesktop to set of users. My understanding is below,
Users who are accessing published application as XenApp; is a thin client application.
users who are accessing using XenDesktop; is a thick client application.
Is my understanding is correct? I googled a lot but still couldn't get a proper answer. I am very new to this Citrix world.
Can someone please explain me in laymen language?
I'm not sure these categories can really be cleanly applied to Citrix. Let me just explain in a nutshell how it works and you can be the judge yourself which of the (if either) it should be.
I have a farm of Citrix servers that I deploy WPF to. The servers are basically just Windows machines, so I can browse for files, upload, interact with the local file system in any way. The app itself to the Citrix server just like it was a personal computer. Citrix technology basically just transmits a picture of whatever apps each user has open on the server(s). It does this by the user installing a client (web browser plug-in), and all that comes across the wire is the compressed graphics info. There is no discernible lag, so it's basically just like I'm working directly from the server. I can't copy objects directly to my laptop from these web servers, because the OS I'm on there isn't really the same OS (although can browse through the network to my laptop and copy it that way very quickly).
That is Xenapp. I assume XenDesktop is the same as what we call 'Remote Desktop, but double-check me on that. This is what I use to log into a computer in the office from my home and control it. It works very much like the above except that, instead of logging into a server , it's used to log into a desktop PC.
Both technologies just transmit a (compressed) image, and both allow you to send keystrokes and mouse movements so that it's like you're working directly on that machine. As I understand it, Citrix is one of the few games in town with this kind of technology, and last I heard, even MS licensed it from them.
The typical usage is to install fat client apps on a Citrix farm so that they then become web/browser accessible from outside the work place. The apps are published on a gateway web site with links to the individual apps (although you can also browse through the file system and open that way). The only thing the user needs to have installed to do this is the Citrix client to decipher the visual stream. The client is free and lightweight.
So basically, I would say Citrix technology allows for fat clients to be installed on the Citrix server and then accessed like thin clients.
There are a few key differences between Citrix deployment and the way typical web app works. One is that the user has to actually close the app out, not just their local web browser , otherwise the app stays running on the Citrix server. By default that doesn't typically happen because from the Portal, a particular app will be published, so that only that particular app pops up on click of the link (not a desktop or Windows Explorer). So when the close the 'picture' of it running in the browser, they do so by closing the 'X' on the app. But if they're crafty, they're can disconnect the client from the server and leave it running. That can be handy if ones need to some work that shutting downt the laptop would otherwise close out (long-running datawarehouse pulls, etc). Another difference is that speed and performance are pretty much the same no matter the location of the user(at least with XenaPP). Normally, if you have a Wide Area Network, and you say, deploy an ASP.NET web page on web server in City A, the user in City B 1000 miles away may have a bit of a lag, since the web app may have to query a database server, then spit out some Javascript, that then gets consumed and ran on the client. With Citrix Xenapp, everything is occurring on the server in City A. In Citry B, the user is just getting a compressed picture stream. For this reason, it's better to avoid too fancy graphics, because they waste bandwidth and usually get autocompressed to look weird anyhow. But assuming that is done and the farm doesn't suck, performance will be appreciably the same in India or the Philipines or the United States for the same app. Another difference is that the data is inherently Sandboxed, and there are is no URL unless you decide to put the app on a web server and then have users access it through Citrix (which I've seen done in companies with sensitive data using offshore vendors because of the Sandboxing and speed benefits). But if you do that, you have to open the web app from within the Citrix portal and then you can run the browser on that server (you can't just put a link to that web app from the web). Finally--and maybe this is just where I work--but the load balancing seems to work a little differently than with web servers. Users tend to get thrown on the same server if they already have another app open. That can be handy for copying files, etc, but also means less balance in the load for particular servers at times, so that you typically don't want the overall average load to go high (need more servers).
Hopefully that helps explain it and give you an idea. Citrix just sends a picture of the wire that you can use to remote-control a machine. I would say it's kind of "both" on the thick or thin client question. Typically it is used to deploy Winforms, WPF or other 'fat client' technologies, and is largely unnecessary for technologies that already allow for thin clients (web apps). But sometimes web apps are pushed through there also, for various reasons.
I found this article:
www.codeproject.com/Articles/1077937/Possible-ways-to-organize-interaction-between-co,
and I know that there exist a code for the flash player.
Can I use only code for managing connections (as in the articles examples) and free flash player code and therefore get rid from integration software?
You need to be more specific but in reality the idea of the integration software is the following:
Session management
Multi-codec/format support
Interface Resource
Scheduling
Normally IP PBX supports SIP only, hence you need the transcoding between the SIP world (Audio + Video) and the Webcast world (Web browser/client/camera). Integration software as the one defined do a pretty good job and some of them are open Source (Wooza), If you want to replace them, I would do it with an MCU which support RMTP/Flash. Take a look at McuWeb project. Otherwise you need to write SIP Client code as well to integrate it with the SIP world
I am developing a customer account system for a chain of recycling centers in the Northwest US. One of our key features is that our customers can set up accounts that are credited with their bottle deposit refunds, instead of always disbursing cash. Customers can also drop off bags of recyclables that are processed on-site and credited. Each center runs near capacity and can physically process cans and bottles when offline, so we don't have a lot of leeway for IT infrastructure to shut down everything when the Internet goes out.
Basically, I've been asked to develop a customer account system that will allow credits from a retail center to be posted to accounts, even if telecommunications with our central server breaks down for a period of hours. This will allow the center to keep processing and crediting customers when the pipes get clogged. Certain transactions, like withdraws, do NOT need to occur in this situation, since we can't accurately get the customer's current balance.
We are a 100% Windows shop, and the IT manager and network admin don't want to get near anything *nix. Each retail center has an on-premise dedicated Windows Server, so that seems like a logical place to start.
I'm a huge fan of ServiceStack, and the REST-ful message-based paradigm seems like might work. I'd create a "Credit" message and send it to the local server. A message broker there would log the request and attempt to forward that message to the central server where it is processed. In case the central server were down, I would rely on the MQ's reliable messaging protocol to hold on to it until telecommunications are restored. The overall anticipated volume is 100s to low 1,000s of messages out of each center, so low by modern computing terms.
The Redis MQ Client / Server for ServiceStack looks interesting, but since the Windows Redis server is explicitly labeled "prototype" and "not production quality", there is a 0% chance of being able to leverage it.
So, ultimately the questions are:
Is a reliable messaging system the right type of solution for this problem? Are there other approaches I should consider?
Are there alternatives to Redis that play well with ServiceStack? Is there a "production quality" NoSQL server replacement I can use on Windows?
I've looked briefly at RabbitMQ. Might that be an option? My Googling doesn't show any active integration between it and ServiceStack, so I'm leery of writing something from the ground up.
Ideally the overhead of my solution is low enough we can perform a synchronous update and return a "current balance" receipt to a customer if everything is working well. Is this a realistic?
A production solution for running Redis on windows is to run redis-server inside a Linux VM on windows with Vagrant.
There is current a feature request to add more MQ Options to ServiceStack. Rabbit MQ is expected to be the next MQ adapter to be supported in future.
As a follow-up, MS Open Tech has released a "production-ready" native implementation of Redis 2.8.9. GitHub link.
I have a client company with a simple web application (Python Flask) and I need to add a phone notification functionality to it.
The main requirement is that the app should call users, play a certain sound file and accept some tone input ("Hello! This is an automated message from your WebApp account. You have a meeting with $John today at $5pm. Please press 1 to confirm").
The other requirement is that the solution should be relatively cheap and fast to market.
I have done some research already and it seems that there are a few consequent steps to achieve that:
Set up an Asterisk or a FreeSwitch server;
Set up a SIP account;
Write some business logic for the Asterisk server which allows to make calls and play sounds via a SIP account;
Write an API at the Asterisk server and expose it to the Python Flask web app.
Do I miss something here? Can any of the steps be omitted anyhow? Can I do it simpler?
the fastest way to get it working is to use one of the cloud voice services with speech synthesiser. Here's a short list to check out:
Twilio
Tropo
Plivo
Here I listed some details.
Those services charge you per minute, plus you may have to pay some monthly fee.
If you want to run an independent and standalone service, I would recommend FreeSWITCH instead of Asterisk. It's got reach integration possibilities and API. You will need to read the FreeSWITCH book in order to understand how it works and how to build your service.
I agree with Stanislav Sinyagin on the cloud based solutions, but I would add one more, Voxeo Prophecy. Tropo is from Voxeo, but they have offered Prophecy as a solution for a lot longer and it supports the open standards CCXML and VoiceXML. The advantage of CCXML for outbound notification applications is you have a lot more control of the notification process.
The Prophecy platform has excellent call progress analysis (CPA) which will allow you to determine whether a machine or a human answered and handle the call accordingly. For example, it does not make sense to ask a machine to "...press one to confirm". Instead you may want to leave a message that provides a call back number for the user to confirm with after they have listened to the voice message. The CPA can be used to leave a message on a machine at the correct time (when the greeting message has stopped) so that you do not get clipped messages in the voice mail. CPA will also allow you to provide detailed reports on who was notified and for those that did not it can tell you whether it was a bad number (received a SIT tone), a modem or fax answered, or ring-no-answer (pretty rare these days). These type of details can factor into your retry process for failed notifications.
The other advantage to using Prophecy and open standards is your application will be portable to other IVR systems that are VoiceXML/CCXML compatible if you ever want to migrate. Tropo, Twilio, and Plivo all use proprietary API's which does not allow you to move your applications to other services. Prophecy is also available as a software solution so that if you want to take it out of the cloud you can run it on premise. You can get a two port version for free to try it out.
There is excellent documentation on developing outbound notification systems on Voxeo's developer site. Take a look at the CCXML documentation in section F on Outbound Dialing.
Not sure which development languages you are familiar with, but if you are used to ASP.NET MVC there is an open source project called VoiceModel that makes it easier to develop VoiceXML applications. The other advantage of VoiceModel is that you develop your application once and it will run on any VoiceXML compatible platform and Tropo. They are currently working on adding outbound notification support in this project that will work for both Tropo and VoiceXML.
Third party solutions listed are your easy choice. Running your own asterisk is also suitable for what you want to do, but i think for only this much it would be overkill, from an operational perspective.
In asterisk, you can originate a call that has the 2 variables you need with an (basic-authenticated) HTTP request. You will also need some settings and a tiny dialplan. Setting up the SIP account is easier or more difficult, depending on the documentation from the provider. Most of them have detailed documentation for configuring asterisk (not so much so for freeswitch). Keeping the damn thing alive is what's gonna get to you :)
I want client machines on internet who subscribe to my server to donate their idle cpu cycles.(Like SETI#Home)
They would take jobs(work-units) from server to process, and send back results to the server. (This is the most simple description). The framework i need should allow me to define a job/task. Rest of things like communication, job execution/tracking, client binaries update etc. should be managed by framework.
I evaluated Alchemi.NET a bit, but its not actively maintained, seems half-baked.
BOINC has API in C, but i want a .NET or JAVA framework.
I am looking at Manjrasoft's ANEKA , but it seems to work only for LAN clouds.
There must be some such frameworks available. I need expert recommendations!
I'm hardly an expert but I do have a little experience with distributed computing using MPI (with C). What you're talking about does not sound like grid computing, rather a master/slave system. That is your server is the master and it directs all the clients (slaves).
I know very little about .net programming so I'll speak in general.
There are a lot of web frame works out there and probably most have the facilities you'll need. That is your client will be able to upload files with the content they have gathered (or they could just use http get/post), because you don't have to worry about UI issues you can handle everything probably through one action (assuming an action based web framework). Then the server can return a response via JSON or XML which the client can use to take further direction on. JSON is the right choice if the system is very simple and probably a good choice for prototyping.
For the application upgrade I would consider this a separate issue (although it should be a simple matter for the server to return this to the client).
BOINC is the framework that most naturally meets your volunteer computing requirements, and it's stable and highly scalable -- I'd make sure you've considered it completely before ruling it out.
If you need to deliver something to a short deadline then I'd consider working up a simple supervisor (or scheduler) - worker pattern, just to get the application off the ground. The supervisor would be responsible for chunking up the data and making it available over http. Workers (your client app) would connect to a supervisor server; download a chunk of work; complete the chunk; and upload the results to the supervisor.
The main trick is to get the state machine thrashed out properly, so that you can accurately track what state each work chunk is in. I'd have the supervisor persist state in a database in the background.
Does your first release need to be internal, or is it for public consumption?
While that's working I'd get started on looking at getting up to speed with BOINC and planning a migration.
My recommendation
Work dist:
Have a receiver of requests, that places messages in a message queue, like rabbit mq
Have a host of workers, listening to the same queue, taking work from it and acking it when done.
When done, send a message on another queue, containing an URI to a known location, such as your network drive. The target is your parsed data.
The receiver listens to these "completed" messages. Fetches the data from the URI.
Done.
RabbitMQ comes with great CLR APIs.
The same reasoning works well with Microsoft Azure and their AbbFabric Queue. A plus is that is scales extremely well.
Hot Versioning
http://topshelf-project.com/
It gives a folder where you can drop binaries, which are then run. It manages versioning of these as well as running them as windows services.
Deployment
You can deploy the binaries with robocopy/xcopy and "net use Q: pwd \server\share", "net delete Q:"
Continuous Integration
Teamcity
After working with MsBuild extensively, I would recommend scripting it with psake and running the build with PowerShell. If you get advanced with PowerShell you also have WinRM available to you from your build scripts, which is really smooth.
Use the git/subversion commit number as the 0.0.0.x, x in the previous version number, and you will have automatic versioning that is "shared" across "Debug"/"Production" builds.
The Azure way
Work dist:
Same as above but with AppFabric Queue instead of RabbitMQ.
Hot Versioning
By swapping "Staging" and "Production" instances around, you avoid the downtime.
Deployment
You can either tap into the Azure Tools for Visual Studio's MsBuild tasks as can be read about here or you could use the PowerShell AzureSnapIns with a similar setup as above for Continuous Integration.
Continuous Integration
Same as above.
How about .net's ClickOnce installer to manage auto updated client binaries.
http://msdn.microsoft.com/en-us/library/t71a733d.aspx
I'm not sure of a "jobs framework" per-say, but Microsoft's Sync framework to support rolling your own jobs syncing with clients?
http://msdn.microsoft.com/en-us/sync/default