My idea is to have single addressable RGBW LED strips in all my rooms. For the sake of practice and interest, I do not simply want to by some controller, I want to start this project with some custom self-build infrastructure, consisting of some Arduinos and/or raspberry pis. My initial idea was to just setup a simple local server on a raspberry (which controls the arduinos connected to the LEDs) and build myself an app to control the lightning. That part is clear to me and should not be a problem, but I thought it might be a plus to integrate my devices directly to Google Home so I do not need any extra app.
I read through the Smart Home Platform but things are not 100% clear to me. I read things about requirements like public Oauth2 Server. I was wondering, if it is possible to get this working without setting up any server which has to be reached publicly, because otherwise I won't waste time on that topic.
If you want to control your room devices from a smartphone and are satisfied with local operation from few meters away than you should consider BLE on phone and devices.
Obviously, you would need to write your own app, but luckily with BLE you can use publicly available apps such as LightBlu for the dev phase and maybe even for later use (I have not looked into that lately).
Related
What I'm asking here may not be possible at all, due to my lack of knowledge with networks.
I want to start playing around with IOT objects in my house. I would love to be able to control various objects from the touch of a button on my phone.
I have bought a "smart" plug outlet which enables me to turn the power on or off via an app over my home WiFi, however I want to be able to build my own app and control the device exactly how I want to, just for fun.
This app I'm using at the moment comes with the outlet and as far as I can see, it was not meant to be customizable in any way.
My question is, is it possible to figure out the requests being made to and from the device, and create my own API to work with it?
I am a software developer day-to-day however my knowledge in networks is very basic. Any help is really appreciated!
If there is no documented API you can, in theory, to reverse engineer the API using sniffers. If you control the device from your phone you can install sniffers on the phone and see the incoming and outgoing requests. But the bigger problem for you is if there is some kind of security mechanism that the device and the app are implementing. The protocol can be encrypted so you wont be able to understand the network traffic or maybe some kind of key that will allow the device to get orders only from a specific app.
So my suggestion, if you are not experienced with this kind of work is to approach the device vendor and ask them for the API, some vendors would be happy to expose it if you would publish your code and let other customers to use it and expand their product.
*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'm coding an extension for a customer, one of the requirements is that the extension also works offline because internet services are not that reliable, my customer's business can't stop but can deal with "stale" data, thats a nice tradeoff I guess.
Therefore, I want to code some kind of distributed cache as an extension to synchronize local data among the N nodes that will be connected running the same application and thus synchronize with the real database, hosted on the internet.
In order to achieve that I imagined that I would need to make a network broadcast and listen to incoming broadcasts, then every node that starts to run my application will broadcast it's IP address and become available as a new node for the distributed cache, failover is very important here.
I googled some possibilities I initially thought but none of them will work, I guess. The first was to do it just with HTTP, the second was to use Google Native Client to write C++ code that could run network code and thus do the broadcast, but it has limitations. Right now I'm thinking to use Java Applets but I don't really know if they have some limitations related to networking or if Chrome Extensions has any limitation with Java Applets.
Any ideas on how to do it? Using some of the stuff I suggested or another approach?
You could create an NPAPI extension, which would not be restricted by Chrome at all.
Im in need of a solution, I basically require a way to print from a web page to a printer. But the printer needs to be standalone, either plugging directly into phone line, using a sim card etc. Does anyone know of a good solution for this?
It needs to be cheap to run, setup costs aren't that much of an issue, but obviously the cheaper the better.
If landline is okay, I believe the device you want is an antiquated piece of hardware called a "fax machine"
If wireless on a mobile network, the service plan is more of a cost concern than the hardware, though the two might be bundled together. For example, a company called bug labs is working on some kind of partnership with verizon for connecting their embedded linux device construction kit.
What all would be the requirements for the following scenario:
A GSM modem connected to a PC running
a web based (ASP.NET) application. In
the application the user selects a
phone number from a list of phone nos.
When he clicks on a button named the
PC should call the selected phone
number. When the person on the phone
responds he should be able to have a
conversation with the PC user.
Similarly there should be a facility
to send SMS.
Now I don't want any code listings. I just need to know what would be the requirements besides asp.net, database for storing phone numbers, and GSM modem.
Any help in terms of reference websites would be highly appreciated.
I'll pick some points of your very broad question and answer them. Note that there are other points where others may be of more help...
First, a GSM modem is probably not the way you'd want to go as they usually don't allow for concurrency. So unless you just want one user at the time to use your service, you'd probably need another solution.
Also, think about cost issues - at least where I live, providing such a service would be prohibitively expensive using a normal GSM modem and a normal contract - but this is drifting into off-topicness.
The next issue will be to get voice data from the client to the server (which will relay it to the phone system - using whatever practical means). Pure browser based functionality won't be of much help, so you would absolutely need something plugin based.
Flash may work, seeing they provide access to the microphone, but please don't ask me about the details. I've never done anything like this.
Also, privacy would be a concern. While GSM data is encrypted, the path between client and server is not per default. And even if you use SSL, you'd have to convince your users trusting you that you don't record all the conversations going on, but this too is more of a political than a coding issue.
Finally, you'd have to think of bandwidth. Voice uses a lot of it and also it requires low latency. If you use a SIP trunk, you'll need the bandwidth twice per user: Once from and to your client and once from and to the SIP trunk. Calculate with 10-64 KBit/s per user and channel.
A feasible architecture would probably be to use a SIP trunk (they optimize on using VoIP as much as possible and thus can provide much lower rates than a GSM provider generally does. Also, they allow for concurrency), an Asterisk box (http://www.asterisk.org - a free PBX), some custom made flash client and a custom made SIP client on the server.
All in all, this is quite the undertaking :-)
You'll need a GSM library. There appear to be a few of these.
e.g. http://www.wirelessdevstudio.com/eng/
Have a look at the Ekiga project at http://www.Ekiga.org.
This provides audio and or video chat between users using the standard SIP (Session Initiation Protocol) over the Internet. Like most SIP clients, it can also be used to make calls to and receive calls from the telephone network, but this requires an account with a commercial service provider (there are many, and fees are quite reasonable compared to normal phone line accounts).
Ekiga uses the open source OPAL library to implement SIP communications (OPAL has support for several VoIP and video over IP standards - see www.opalvoip.org for more info).