I am just understanding Apple HomeKit for building an demo app.
I see there are few predefined accessory types are given by Apple.
Like Switch, Fan and Thermostats etc.
What if I want to have some new type of accessory, which is not listed by Apple? How do I create this new accessory (I know that this new accessory need to be manufactured by a Hardware manufacturer, and for that it needs to be registered as apple device manufacturer)?
Does apple allow to create new accessory type?
You almost answered the question yourself. In order for a hardware to be classified as an 'HMAccessory', the hardware needs to be 'HomeKit' certified (see MFi Program.
The hardware manufacturing vendor will complete the MFi licensing procedure - in the process defining the accessory type.
So you don't need to worry about dealing with an undefined accessory type while programming a HMAccessory. By virtue of being an HMAccessory, that should be resolved for you.
Related
I'm learning about Bluetooth (and LE), and I'm writing simple desktop application for Windows 10 to communicate with different kinds of BLE fitness devices.
I have Bluetooth up and running and I can send and receive data, but I have a small problem; sometimes I don't get correct manufacturer name from "Manufacturer Name String". I need to know the manufacturer so that I can send manufacturer specific commands to the devices.
The problem seems to be related to different computer hardware and/or drivers, because the problem happens only on my friends computers, not on my computers. The devices I use don't support "PnP ID" and "System ID" so I can't use those to get needed information.
I also read somewhere that I can use MAC address to know the manufacturer, but the devices I use don't give me the address in a format that can be used to get Company Identifier.
What else can I use to get the manufacturer name and/or code?
If the advertising data contains a manufacturer data record, the 16-bit manufacturer id can be looked up here:
https://www.bluetooth.com/specifications/assigned-numbers/company-identifiers
Looking at the MAC address will probably be very unreliable, as many BTLE devices use a random MAC address for privacy reasons.
However, there is also the UUID of the individual BTLE characteristics, which contains a manufacturer code. See here for a list: https://www.bluetooth.com/specifications/assigned-numbers/16-bit-uuids-for-members (note that this applies to shortened 16-bit UUIDs, not to the full 128-bit ones).
Considering most of the fitness devices follow GATT specification, 0x2A29 uuid corresponds to org.bluetooth.characteristic.manufacturer_name_string.
https://www.bluetooth.com/specifications/gatt/characteristics/
I am looking into persona devices as described in Appendix G of the Redhawk manual.
Is there a detailed "how to" for this anywhere?
In my scenario my 'Programmable Device' would be a Redhawk FEI device that interfaces with a kernel API that controls tuners, fans, gps, buttons and LCD displays. I would like to break this out into three or four persona devices that interface with the main FEI Device.
Thought I'd ask.
If you head to Geon's github and look at the RFNoC_ProgrammableDevice and RFNoC_DefaultPersona, you can get an idea of how these Devices interact with one another. It should be noted that these Devices are still under development. Unfortunately, the manual appendix you mentioned and these examples are really the closest thing to a "how to" there is right now.
That being said, this pattern is generally reserved for FPGAs, with the programmable Device controlling access to the programmable hardware (and FEI functionality, if present) and the persona(s) controlling access to specific bit file capabilities. If you're not interacting with an FPGA, then the pattern will most likely be more trouble than it's worth to obtain modularity.
I was wondering if it is possible to modify the contents of a BLE beacon to include extra information. If you insert an extra bit at the end you could potentially broadcast a boolean in one direction. Theoretically, if you modified your device to read the extra bit of information this would work. Given existing protocols though it sounds like this would be a lot of work. Is there something out there like this already?
For info, I'm working on the mbed platform where you can modify your own bluetooth beacon payload.
Yes, you can do this with the new AltBeacon specification. There is a one byte manufacturer reserved field which you can use for whatever you want (tied to your manufacturer ID).
There are reference implementations of the specification available for Linux to show you how it works, and there is no reason you cannot implement it on the mbed platform.
Are there programmable barcode readers which I can put program in it. With that program I can tell the reader what are the valid codes. So the reader will refuse to read invalid codes.
Or, with that program, I can encrypt the codes it read.
And, can I use Java to make the program?
There are various types of bar code readers from hand held scanners to counter top scanners to scanner attachments for mobile computers. Most use a USB connection though some use a Serial Port connection. Some are attached to a portable device such as a tablet and some such as a hand held scanner are plugged in. Some hand held bar code readers can also be used as a standing scanner which stands on the counter and do not have to be held.
The two major types of bar codes that I have seen are the standard bar code with the vertical lines of varying widths - see also bar code types from GS1.org - and the QR code from Denso Wave. Commercial point of sale scanners such as counter top or hand held scanners are designed for standard bar code with some also offering the ability to read QR codes. However not all hand held scanners can read QR codes.
Normally the bar code reader will scan the bar code and generate a text string which is then processed by some other device such as a point of sale terminal. I have not seen a bar code scanner that will allow a Java program or similar programatic changes. However there are kiosk type or small devices with a built in scanner which are programmable. See this selection from Symbol.
Bar code readers with a USB connection typically have two ways to configure the drivers, as a HID type of USB device or as a wedge keyboard type of device. The wedge keyboard type of device is usually easier to interface to because it is the same as just reading text from keyboard entry. When using wedge keyboard type of interface, you will typically program the bar code scanner to generate a guard character so that when that character comes into your application you know that it is text generated by the bar code scanner and not from someone typing.
Some types of scanners will have an OLE for Retail POS OPOS Service Object that can be used with an OPOS Control Object. This approach provides device independence for your software since you would write your application to use the OPOS Control Object interface which solves a number of interface issues such as talking to the device using the HID USB interface. However OPOS is a COM type of interface which may be difficult with the Java programming language. Search for information on UnifiedPOS to find your way to the latest standards.
Hand held scanners will have factory settings out of the box and these settings may not be suitable for your application. The hand held scanners I have used can be programmed and their settings changed by a procedure in which special scan codes are scanned in a particular sequence. Normally the user manual for the particular scanner will have an appendix or two with the documentation as to what settings can be changed, the procedure or steps to use to make changes, and the bar codes to be scanned for the procedure steps. You will probably need to search the manufacturer's web site for the appropriate manual.
For instance the Motorola LS2208 Product Reference Guide contains various sections on setting up that hand held scanner for various environments and scanner applications. The following screen shot from a page of the guide shows the bar codes used to set up the device for USB interface.
Another option would be to have an application on a phone that uses a phone camera as the bar code scanner. However it appears that most cameras are not good for standard bar codes.
Most scanners for retail systems are fairly complex with lasers for the actual scanning. I have used several different types with point of sale application and they are all fairly easy to use. You can change the settings by entering commands using a set of bar codes which are part of the documentation. These settings are for such things as bar code symbology, prefix characters, suffix characters (prefix and suffix characters are used with wedge keyboard type of interface).
See this forum discussion on using a camera for standard bar codes.
See also this web page on Android bar code scanning.
We are considering using the vendor and product ID of a USB device (obtained via IOKit) to unlock certain features of an application. I'm aware that these values can be spoofed, but I'm not sure how easily it can be done on OSX. What is involved in spoofing the vendor and product ID? Is it something that a non-programmer can do fairly easily?
I suspect it would be fairly easy (for a programmer) to create a kext that creates a reasonably realistic IOUSBDevice object in kernel space. However, once done anyone would be able to load it.
It may also be possible to build a codeless kext using AppleUSBMergeNub to masquerade a device as another (though I haven't tested this, it looks like it might work, assuming you only try to match the IOUSBDevice without actually using it).
It would probably be easier to just hijack your API calls in userspace and give your software the answers it expects.
A non-programmer cannot do that. What you can do is writing a kernel extension (an IOKit driver) for the device, that has a matching dictionary matching the real vendor-/product-ID of the device, which causes the system to automatically load the kernel extension when this device is connected and pass a reference to the device object. The driver is now responsible for initializing the device and create all necessary user space information that is necessary for the IOKit framework (the user space library) to communicate with the device. Usually Apple has default IOKit drivers for most USB device classes (that's why you don't need an extra driver for every USB mouse or keyboard for example), but if there is a more specific driver found, then this driver will be used instead. And when creating the user space data, of course the driver may lie about the vendor-/product-ID, causing the user space program to see false values. Since IOKit is written in C++ and heavily depends upon objects and object inheritance, it is not even necessary to write the driver from scratch, but instead it can inherit from Apple's default driver and just override some methods and otherwise rely upon the super implementation. However, writing IOKit kernel drivers is not that easy and even people developing Mac software for years may have no idea how to do that and the IOKit documentation is one of the worst ones Apple is offering.
So to answer your question: Is it possible? Yes. Is it fairly easy? No. Can non-programmers do it? Certainly not, unless someone else has written a ready to use extension for them, that they only need to install.
It's actually rather EASY, and I'm definitely not a programmer!
Found the guide here
http://rolande.wordpress.com/2012/10/25/getting-the-aten-usb-serial-adapter-working-with-mac-osx-lion
Thanks, Rolande!
I was able to change the IDs of a USB Ethernet adaptor I bought on eBay to use another driver with Mac OS X 10.8.
Since nobody has answered so far, I've stumbled across a page which basically says that you can get an Arduino and program it to return any VID/PID/serial that you want. I still can't find any software-only way to do this.
I can create A OCX in Delphi code to do that
And supply infomation to send/receive data to the USB with other states like:- is it still connected.
Natraly I need a little more detail than that in case that same chip is connected from another product.
example frendly name, device desription.............