I am currently evaluating IoT platforms which can connect to devices and controllers, then collect data and do some analytics
To start with I have this device "JACE 8000" which runs on Niagara platform, which has communication protocols like obix, mqtt etc
I would like to know if Kaa already has any existing module or plugin for this?
If not how to build a new one? and how easy is it to develop a new plugin
It appears that Kaa's preferred choice of protocol is MQTT. Niagara N4 happens to provide an abstract implementation of an MQTT driver, so I'm confident that would probably be your best route for development if you wanted a JACE to communicate with a Kaa network.
To go into any more depth is difficult here because you really need to be either a certified Niagara engineer or developer and have access to a workbench, documentation, and so on. The Niagara framework is a big beast!
Related
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".
*If you think I should ask this question elsewhere, please let me know.
Background:
I need to build an application for converting weights into piece counts. The weights currently come from scales that are connected to PCs via serial ports. I am replacing PC based applications that connect to the scales via a serial connection. I am considering the feasibility of making the next generation of these applications into a web based solution. However, I do not want to do this if it is not a better solution than building an application that runs on the client. In addition, I do not want to use any sort of browser specific technology (ActiveX).
FYI, we currently run a Windows based environment.
What I have so far:
I am currently thinking that I will need some sort of client side “service” to allow the scale data to be retrieved by the web application. I have looked into creating a WCF service for this task and have determined that it would probably work. This would require that the scale be connected to some sort of Windows based computer that is on the network. I would then interface the WCF service (running as a Windows Service on the PC) from an ASP.NET web application running on an IIS web server. This would minimize the footprint on the client and allow us to use a web application.
I am looking for any constructive thoughts and ideas. I am open to reviewing any feasible option that would make this solution as simple and reliable as possible.
Answering my own question per request #honeycomb.
I discovered two viable options for this purpose. Following are high-level overviews of the techniques we leveraged.
Develop a scale reader to be run on a PC connected to the weigh scale device via an RS-232 connection. This reader will forward any information received from the scale into a database. Combined with technologies like change notifications and server-side push notifications, this option will allow data from a weigh scale to be pushed into a web page with little effort and no additional cost. (This option has performed well during testing but is not yet in production)
Invest in converting weigh scale devices to use ethernet connections and connect them to the network. Use an OPC server with a driver that can connect to the weigh scales you are using to read the data from these devices. Consider KEPWare's offering for this purpose. Use KEPWare's tools to forward this data to a database or wherever it is needed. Once again, you can leverage change notifications and server-side push technologies to push this data into web applications in near real-time without polling. (This option is currently working in a critical, production environment)
The second option is probably better in the long-term, but this may vary based on your specific situation. It has some up front costs and would be better suited to new implementations. For my system, I am using the first option because it will ease the transition between the new and old systems.
Note: I am not in any way associated with KEPWare. I am only suggesting their product because it is the only one I am aware of that supports this functionality. I am sure there are other OPC servers that support this type of device.
I was assigned with the re-architecture of a legacy (medical) product which is controlling several external devices. In the current architecture, we have several such stations in each customer's network, where each station is processing its own data, and they all share some of that data via a central server (that talks to the DB and BLOB storage).
I'm planning the new architecture such that it will allow more scenarios, such as monitoring the stations through a web interface, and allowing data processing to be scalable by adding additional servers.
This led me to choose NServicebus as the messaging and communication infrastructure. And I pretty much have a clear view of the new architecture.
However, another factor was recently added to the equation by my manager. He requires that the machine that communicates with the devices (hardware), will not be under the IT policies of the customer. The reason behind this, as I understand, is that we don't want the customer's IT to control OS updates, security, permissions and other settings, because we want full control over that machine in order to work properly with our hardware.
My manager thus added a requirement that this machine will be disconnected from the customer's LAN.
If I still want to deploy NServiceBus on that separated machine (because I want to pub/sub async messages to other machines - some are on the customer's LAN and some aren't), Will it require some special deployment? Will it require an NServiceBus gateway?
EDIT: I removed the other (1st) question, as it wasn't relevant to the scope of StackOverflow.
Regarding question 2, yes it would require the use of a "Gateway", however the current NServiceBus Gateway implementation does not support pub/sub so you would have to look at alternatives.
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
I'm writing a windows service that will be used for some data processing. The service will connect to an OPC (KepWare) service and will monitor specific items through event handlers. It will also have to write back to the OPC data item when necessary; however, the data to be written back will have to come from a windows mobile handheld device.
I'm just getting perplexed on the design aspect of this system. I'm trying to make sure that I design this in an abstract manner in order to make it scalable and easily maintainable. However, I'm just stuck on how to communicate with the service in order to tell it write this value to the OPC server. I'm thinking WCF is the way to go but I'm not exactly sure how to write it where I can obtain a reference to my connected OPC object when the client makes the call? Should I be writing a WCF library and host it inside the windows service or should I be going down a different route?
Thanks in advance
You should read up on the fundamentals of OPC-DA and OPC-Xi (also known as OPC .NET 3.0). The OPC Foundation has simple documentation available for free: look for the "specifications" that are available to non-members.
The KepWare server should support both (depending on the KepWare server you are using). OPC Xi is WCF-based and will be the easiest way for you to talk to it. However, that particular communication channel needs to be open and enabled for it to work.
If you don't have that, then you need to fall back to OPC-DA which is DCOM based. You can find .NET OPC client libraries that will help you with this. There are some free and some commercial ones out there from different companies.