I'm trying to get some initial info on my very first IoT project. I want to build a * tiny * wifi connected relay to control, let's say, lights. I'm a newbie in the hardware and electronics field though, but I'm a pro developer, so programming is not a problem.
Now, I've looked at different options and I can't seem to find really small components for the task. It might be I overlooked something, so please help me with available options.
Look at the ESP8266 devices. They have WiFi on chip and can be programmed using the Arduino environment. You basically write code in C++ to do whatever you need.
Here is an Amazon search for some examples:
https://www.amazon.com/s?k=esp8266
I recently did a project using a Linknode R4 (similar to above but with 4 relays) and programmed it as a web server with REST API. Then I built a front end with ASP.NET Core to that talks to the REST API for the devices on my network. The Arduino sketch for the web server is posted on Github at https://github.com/SteveInCO/LinknodeR4. I would assume it would work with little modification on the device I linked above.
The default program for the R4 allows controlling it via their website or iOS/Android apps, though I could never get it to work out of the box. Their model uses a polling method so the relays continually ask the server what to do next.
Windows IoT doesn't run on these small devices yet, but no reason you can't front end the Arduino API with a UWP app running under Windows IoT on a Raspberry Pi instead of the web app like I did. I think the eventual plan is for ASP.NET Core to be able to run on an ARM based system like a Raspberry Pi, but last I checked it wasn't quite there yet.
Related
I am starting to develop for Android Things and I was wondering if it was possible to implement OpenThread Border Router on a Raspberry PI 3B with Android Things flashed into it.
https://github.com/openthread/openthread
https://github.com/openthread/borderrouter
"A Border Router connects a Thread network to networks at different layers, such as WiFi or Ethernet. OpenThread Border Router provides end-to-end IP via routing between Thread devices and other external IP networks, as well as external Thread Commissioning."
Update: While Border Routing functionality isn't available on Android Things, the Android team released a new API that adds first-class support for Thread radios. This makes it possible to develop Android applications that implement border routing functionality equivalent to borderrouter. See the blog for more details. Note that I'm not aware of any implementations at this time as I no longer work on the project.
---------- Original reply ----------
I work on the OpenThread team. Currently, the borderrouter project targets Linux platforms and has been demonstrated on a Raspberry Pi 3 running Raspbian Jesse Lite. Android Things is not supported at this time. We plan on supporting more platforms but I have no updates of when new ones will be added. Please file a feature request issue on Github.
Working on an appliance and would like to support zero configuration feature. That way users can look for the device on the network and simply double click an icon to access the web interface without having to configure it or know its ip address.
Tried to use UPNPLib_TLB but functions seem to be read-only; am I right? I can create a device using CoUPnPDevice.Create but can't set a FriendlyName or a URL.
Tried to use Deltics Bonjour service but it crashes on create (ACCESS_VIOLATION). The demo code uses a custom test unit which complicates experimentation.
After much research it does not look like there is a component available for this and would appreciate some pointers. Has anyone successfully created a zeroconf broadcast either via UPnP or Bonjour with Delphi XE2/5.. I can go back to Delphi 7 if required. Target = Windows 7.
NOTE: To be clear, I can find existing devices on the network and don't want to enumerate existing devices but what I want is to broadcast my service so that my box behaves like a network printer for example. The only service I need to expose is the URL so that users can access an embedded web server.
Appreciate the help!
EDIT
With the tips provided I did some research and getting this done the RAD way is not possible.
Using MS APIs directly is time consuming and requires a level of understanding of C that I don't have. Porting the Delphi 5/Indy 7 component to XE2/5 will require a good amount of work and debugging.
I discovered UPnP developer tools from Intel now open source here: Developer Tools for UPnP. This tools makes it really simply to create a server in 10-15 lines of code. Intel provides a DLL that I can call from VS Express as follows and it works great:
device = UPnPDevice.CreateRootDevice();
device.FriendlyName = 'My name';
device.PresentationURL = 'URLToEmbeddedServer";
..
I tried to use headconv7 tool to convert the .h file Intel's UPNP.DLL to a pascal file and call the external functions within the DLL directly from Delphi but there were too many problems with the conversion.
It's too bad because the Intel library makes it really simple to create UPnP stacks and the approach would apply itself very well to a component but for now its quicker to use .NET and VS Express to get the job done.
When using UPNPLib_TLB, you are not supposed to create a UPnPDevice object directly. UPnpDevice describes a known device on the network, which is why its properties are read-only.
Read the documentation:
Control Point API
Finding Devices
You are supposed to create an instance of the UPnPDeviceFinder class instead. Its search methods will give you a UPnDevice object for each device that is found.
I'd like my Blackberry devices to get and possibly set data to the server, and am a little confused by all the options:
RIM-Push/Pap-Push. Use any library that is able to compose a HTTP GET request to the MDS-CS service (not MDS-IS). This is a one way operation from the server to the device.
RIM-Push (Push a URL and or shorcut to a device for possible offline viewing)
PAP-Push (Same as above, BUT allows for message confirmation of delivery)
WebServices: Use Visual Studio 2008 to create a Web Services only project. I'm unclear if this is supported anymore, or if MDS-IS is used. This is a 2 way operation.
MDS-IS: Use Eclipse to develop the applications and Java is required, I am unsure of what client libraries are able to do (2 way operation).
Let me know if missing any option, or if I need to revise my understanding of the basics
This is actually quite a broad question - there are a lot of ways for a BlackBerry device to interact with a server, and the ideal way depends heavily on your specific application.
Generally:
MDS Studio: the Visual Studio 2008 method is no longer actively supported. It was a mostly visual forms designer, but not a great solution for a lot of reasons. Basically, don't use it.
Mobile Web: Depending on what you need to do, this might work. Everything server side. The thing to be aware of (and why this doesn't work for a lot of problems) is that prior to BlackBerry 6 the browser wasn't very capable, either in terms of HTML support or JavaScript support. You can, however, create shortcuts to mobile web sites which appear as icons on the BlackBerry homescreen. And you can use BlackBerry Web Signals: http://na.blackberry.com/eng/developers/browserdev/websignals.jsp to push changes to mobile web pages to devices
Widgets: Supported in BlackBerry OS 5 and higher. http://na.blackberry.com/eng/developers/browserdev/widgetsdk.jsp These are packaged much like 'native' BlackBerry apps, but written using HTML and JavaScript. Can be a good option for rapid development if you're ok with just targeting OS 5, and with the limitations of the BlackBerry Browser. Lots of JavaScript hooks to system functions, so they give you more functionality than pure mobile web, and you can distribute them through App World and the like.
Java Apps: Most development work, but you get potentially the best user experience, and the most functionality. Too broad a topic to cover adequately here, but there are a lot of questions related to these on SO and elsewhere. A good starting point is the BlackBerry developer zone: http://www.blackberry.com/developers RIM Push and PAP Push both fall into this category, as they interact with Java apps, though there are other methods that you can use to achieve similar results (client polling, or I've even seen SMS or email used to push info or wake up a client, though this isn't recommended by RIM).
For a deeper overview of the options I'd recommend a book by my friend John Wargo, called BlackBerry Development Fundamentals. He covers the various options pretty well.
Just got a car with the Microsoft sync system in it. Did a quick search online and was curious if anyone is aware of any SDK that may exist, sample open source add-on applications, etc.
Thanks in advance.
UPDATE:
Looks like Ford has finally released their SDK:
https://developer.ford.com/
Ford has a website SYNC Mobile Application Developer Network but the SYNC SDK does not look to be available yet (their site mentions possibly later this year). It appears they are stilling working on the API before releasing it. All they are offering now is a way to register to be notified of new info as it becomes available.
From their About page:
Ford is hard at work developing an API
to allow developers to integrate their
Smartphone applications with SYNC. The
Developer Program website will educate
developers about the Ford SYNC
platform and how to interact with it
via the API. There will be a full set
of documentation, example
applications, reference libraries, and
even a developer forum so you can
reach out to the community for quick
help.
With the available SYNC API's, mobile
application developers will be able to
do some of the following:
Create a voice UI for your application using the in-vehicle
speech recognition system.
Write information to the radio head display or in-vehicle touchscreen
Speak text using text-to-speech engine.
Use the in-vehicle menu system to provide commands or options for
your mobile application
Get button presses from the radio and steering wheel controls.
Receive vehicle data (speed, GPS location, fuel economy, etc.)
The official API and full website
launch is set to be targeted for later
this year.
It looks like the SDK is coming very soon. The story was just posted on Engadget:
http://www.engadget.com/2009/12/18/ford-to-give-sync-some-app-store-flavor-opening-api-to-devs-in/
Now just imagine what you could do with access to your automobile functionality!
I don't think there is any. Its a closed ecosystem.
http://www.autoblog.com/2009/01/09/ces-2009-sync-could-one-day-add-app-development-like-iphone/
From what I understand it is based on the CE 6.0 platform using windows automotive 4.1, but I could be wrong. We really need a forum to get this going. Hurry up Ford! Release the SDK!
Given the way Windows automotive is there is only two ways of putting a ROM on Sync. Using JTAG to put your own custom bootloader (forget it), or though the USB. Which you will need to know how to sign the file so sync will think it is an OEM ROM. So at this point even if you were able to come up with your own custom rom by using Microsoft eMbedded Visual C++ you would still have no way to get it on there.
BTW, the SDK they are talking about releasing will only be to develop apps for applink. (not modifying the OS). However, to upload the apps we might be able to find out how to sign the .bin file for sync to accept a ROM through the USB.
Then again this is just from my understanding... I am no great developer or anything.
Ford launched sdk in ces, check it out: http://techcrunch.com/2013/01/08/ford-launches-its-openxc-sdk-and-hardware-specs-to-let-developers-access-its-cars-sensors-and-metrics/
We have a range of PC demonstration programs for our microcontroller products. The programs typically connect to a USB HID chip on the microcontroller board. The USB chip acts as a communications bridge, allowing the programs to communicate with the micros over SPI/I2C/UART. The programs can configure the micros, and get back status information to display to the user.
We are now looking to build some standalone demonstrations using single board PCs. We would like to reuse as much as possible of our existing demo app source code. Ideally, we could just run them as-is.
Does anybody have any advice on the best way forward? The basic options seem to be WinCE or XP Embedded boards. WinCE boards seem to pull less power, which would be an advantage from a battery life point of view.
Our existing demos are built either in C++ under Borland Builder, or in Delphi.
Thanks in advance.
EDIT: see my answer below with info from a board vendor.
Free Pascal/Lazarus can compile some forms of Delphi apps to WiNCE/arm. Even visual ones.
There isn't a Delphi version for WinCE, so you would need to rewrite the applications. The same applies for the Borland Builder's control libraries. Only if you have used plain Win32 API, you would be able to port your application to WinCE easily. You may also encounter problems with the hardware access part. The Serial Port driver may not work as is. Also, you need to find a WinCE board that can act as USB host and provides HID drivers (this isn't very common).
In conclusion, I believe that you would be better of with Windows XP Embedded boards. These should run your applications as they are.
As an update, and for future reference, I thought I'd post the results of our discussions with a WinCE board vendor here. Caveat: I haven't actually tried any of this.
The bottom line is that there isn't a straightforward way to do what we were hoping for (i.e., re-compile our existing demo applications to run under WinCE). The reason is that the generic HID drivers and standard APIs that exist in desktop flavours of Windows just aren't there in WinCE.
To talk to HID devices in WinCE you need to implement a custom HID driver. This needs to support an interface allowing user mode applications to communicate with the driver, and to construct HID reports to be sent to the physical device. As this interface would itself be custom, application code needs to be updated accordingly.
WinCE application development is generally done using Visual Studio and the Microsoft compilers. The approach recommended to us was:
Create a custom HID class driver. This could be based on, for instance, the Microsoft keyboard HID driver.
Create an API for talking to the driver.
Use .net to create our GUI applications, and use PInvoke to actually talk to the API.
The end result of all this head-scratching is that to avoid the time and learning curve associated with this approach, we're going to go for a board running XP. We can then use our existing demo applications straight out of box. The trade-off is that we'll have to live with substantially reduced battery life.