Here's what I need to do:
Select a single parameter from a screen (preferable) OR enter a code for that single parameter.
Scan a QR code
Update my MySQL database with the data.
Return 'success' or 'failure' in some form (Preferably with bit of explanation)
--
What I can't find is a scanner that communicates directly with my remote server.
I'm considering a smartphone app, but nobody's thrilled to use their personal phone for work.
I've looked at many scanners, but they all connect to a smartphone or computer. I need a programmable standalone device to talk directly with my server.
I'm considering building the scanner out of an arduino or Rhaspberry Pi. It sounds simple enough (not that I have experience in such), but I have a hard time believing this product doesn't already exist.
I'm open to any advice/direction.
Related
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).
I have tried the sample code found at https://learn.microsoft.com/sv-se/samples/microsoft/windows-universal-samples/bluetoothadvertisement/. C#.
It uses the class BluetoothLEAdvertisementPublisher. I have built that on my machine and executed it. I start the advertisement in foreground (or background) and then start an app on my phone (LightBlue and BLE Scanner tried). My PC isn't seen (I do see other devices)
The same when I try to write similar code myself. I have also tried writing a GattServiceProvider implementing a number of services. When I publish that one, I do see the services on the phone, and can read and write to them. So yes, bluetooth IS enabled and working (to some extent) on my machine.
I have latest version of Win10, with Intel AC8265 (with latest Intel drivers). It supports Bluetooth 4.2.
So why can't I see the advertisement? There are no error messages at all and the callbacks reports the advertisement is started as it should.
I'm also a bit confused by the relation between the BluetoothLEAdvertisementPublisher and the GattServiceProvider. Both do "publish" and the GattServiceProvider seems to be able to announce itself. But there is no way to add CompanyId or ManufacturerData to it. Shouldn't both be used? And both working...
To be more specific, it looks like the GattServiceProvider does actual advertising, but only advertising the computer name, bt address and service guids. No CompanyId or ManufacturerData at all. Googling around I found some people claiming that Company Id isn't required in advertisement, and others saying it is (and has to be registered). If Microsoft is advertising without Company Id, then I guess it's allowed.
And I can kind of understand if I'm not allowed to advertise an Intel NUC as having a Company Id from a totally different company. But if that is the case, one would think that the BluetoothLEAdvertisementPublisher would give some error code when used on a Win10 machine?
I've been working on a device that includes an ESP32. I set up a secure GATT server similar to the Secure Gatt Server Example with a custom service with Man in the Middle (MITM) based encryption. Currently pairing setup is Just Works, and when a client connects to the device they are prompted to pair and thus are bonded with key exchange (although it looks like Justworks disables MITM when I did more investigation for this question).
We do not have any real IO except for one button on the device, but I would like to limit pairing to a certain window of time after the Pairing button is pressed, or to have a "pairing mode" that the device enters (I have worked on another device that may have more of a classic pairing mode that was easier to work with). I know that's not explicitly part of the IDF API, but I'm looking for some guidance on how to approach something like a "pairing mode."
Would setting the IO capability to ESP_IO_CAP_IO work for using a button for the Yes/No? I don't see anything relevant in the documentation about how to configure this. In fact the enum does not appear elsewhere in the IDF sourcecode, nor does the mentioned relevant file stack/btm_api.h help.
Is there a way to disable / enable pairing on command? Would it be some type of change to advertising?
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).