Jonathan Witthoeft


Recent Posts

Bluetooth in Home Automation and Internet of Things

[fa icon='calendar'] Aug 14, 2017 1:25:11 PM / by Jonathan Witthoeft posted in Bluetooth, home automation, Internet of Things, IoT, smart home

[fa icon="comment"] 0 Comments

Home automation has been on the rise as the cost of integrating wireless communication in devices has dropped significantly. Amazon Web Services (AWS), Apple’s iCloud, and Google’s Cloud have given people the means to remotely monitor and control their homes. However, where does this leave Bluetooth in home automation and the Internet of Things (IoT)?

Bluetooth for Local Access

Bluetooth has not been a stranger to local automation with many devices that we control using it. From wireless speakers to LED light bulbs, many manufacturers provide smartphone apps to control their devices via Bluetooth. The newest Bluetooth specifications have incorporated Bluetooth Low Energy (BLE), which has made smart, battery-powered devices more accessible without having to recharge or change the batteries on a frequent basis. This gives Bluetooth an edge over Wi-Fi, which is a more power hungry technology. Now, you can place home automation products anywhere without being restricted to power outlet locations. No more need for power strips and bulky power supplies when devices can run for months on a single battery. This is great for local home automation, but since Bluetooth cannot connect directly to the Internet, how can we access these devices remotely?

Smart Home Hubs for Remote Access

This is where we introduce the smart home hubs. Recently, the biggest players in IoT have been releasing voice-activated assistants for your home. Apple just announced HomePod which brings the voice control and intelligence of Siri to your home. This is to be compared to Amazon’s Echo and Google’s Google Home. All of these popular home assistants have two things in common: voice control and Bluetooth radios.

Through the appeal and convenience of a voice-controlled home assistant, these companies have placed a Bluetooth-to-Internet gateway in your home. These smart home hubs serve a dual purpose by providing the user with voice control as well as remote access to their Bluetooth smart home devices. Currently the Echo and Google Home can only be used to communicate with the devices already on the cloud with local Bluetooth devices currently needing their own proprietary solutions to relay information to these corresponding clouds. Apple, on the other hand, through the HomeKit protocol, has defined its own standard for IoT inter-device communication. As long as these devices are designed according to HomeKit specifications, a user can access the HomePod, an Apple TV, or an iPad left at home to control local Bluetooth devices remotely. Google Home, on the other hand, has taken the approach of communicating with other proprietary smart home products, but has not yet utilized a standard for smart home devices. Therefore you are limited to a number of specific manufactures if you want compatible smart home accessories.

With the use of in-demand smart home assistants and the wireless power saving advantages of BLE, Bluetooth has an edge over Wi-Fi when it comes to home automation and IoT. Devices can be designed smaller, with greater battery life, and installed virtually anywhere in the home. Imagine Bluetooth sensors for door locks, temperature, lights, windows, motion detection, leak detection, power outlets, blinds, and much more. Bluetooth devices are now accessible from your fingertips anywhere in the world and are truly the future of home automation.

 

Read More [fa icon="long-arrow-right"]

10 Things to consider - DIY cloud based home security VS. home security companies

[fa icon='calendar'] Apr 28, 2014 12:30:28 PM / by Jonathan Witthoeft posted in Cloud, ConnectSense, DIY, DIY Home Security, General, Home Security, Internet of Things, IoT, Remote Security, Sensors

[fa icon="comment"] 3 Comments

I recently purchased my first home. While the property was vacant and owned by the bank, the screens were split in an effort to try to break into the home. Luckily the doors and windows were locked at the time and the offender decided to walk away. This made me consider security when I moved in and I weighed some options. I want to feel safe while away from home and wanted to be prepared for a break in, but the costs associated with security systems are way too high. This is why I decided to go with a DYI solution and ended up installing the ConnectSense line of products. I now have peace of mind with no additional costs and without the headaches involved with home security service providers. The following is a list of things to consider before jumping into a conventional security service.

1. Installation

Most home security companies require a technician to come and install security systems. Not only are you inviting a stranger into your house, but this could cost hundreds to thousands of dollars. It is especially expensive if your home isn’t pre-wired or you go with an elaborate system. With DIY security sensors like ConnectSense, you do not need to run cables because they are wireless, you can mount them anywhere there is a Wi-Fi connection, and the installation takes less than 5 minutes for a non-technical person.

Grid Connect-5216-Edit

2. Monthly Fees

Monthly fees for a monitored security system can range anywhere from $25 to over $100 a month and typically require a several year contract. That usually exceeds the average annual homeowner's policy discount for having the service. These fees do not apply to a DIY security network. The system automatically does the monitoring for you and will send you a notification in the event there is a security threat.

3. False Alarms

Approximately 80% of reported alarms are false alarms. When this alarm is received by a security monitoring center and they contact the police, you will be billed for the false alarm. With cloud based DIY sensors like ConnectSense, you get notified directly (via email, phone call, text, or tweet) instead of it going through a monitoring center. You can use your own judgment whether or not to call the police. This will save you from expensive false alarm fees.

4. Response Time

False alarms overwhelm security monitoring centers do to the high amount of them. To avoid these false alarms, monitoring centers set rules that allows the resident as long as 2 minutes to disable the alarm before they notify you or the police. This gives an intruder 2 extra minutes. With a ConnectSense security system, you personally get notified within a minute of a security threat.

rule

5. Activating/Deactivating

Monitored home security systems work only if you remember to activate them. This requires you to arm the system whenever you leave and disarm the system whenever you get home. With cloud based home security systems like ConnectSense, there is a scheduler that allows you to select what times and what days of the week you want to receive notifications for specific sensors. You can essentially make a schedule for when the security system, or part of the security system, is active and when it is not active.

Schedule

6. Power Outages

Most monitored security systems will not work with a power outage. Even if they have a battery backup, it will work for at most a day. ConnectSense cloud based security sensors can be powered by outlet or batteries. On batteries, these sensors will work up to 3 years. All you need is a backup battery for your Wi-Fi access point.

7. Remote Accessibility/Deactivation

With monitored home security, in the event of a false alarm, if you want to remotely disable the alarm, you would have to call your security monitoring center and tell them to disable the alarm. With cloud based DIY security like ConnectSense, you can adjust rules and disable sensors from any device with an internet connection.

8. Environmental Monitoring

Most home security companies have some basic environmental monitoring sensors available that are geared toward safety. These are usually smoke detectors and CO2 sensors. With cloud based sensors like ConnectSense you can add other sensors like temperature and humidity sensors, water sensors for detecting basement floods, light sensors, and motion sensors. And all sensors can also trigger output devices such as a smart alarm siren strobe, 0-10VDC digital output, or a power relay output in order to control a sump pump, cooling system, audible alarm system, etc.

Sensors

9. Use of Third Party Sensors

Home security companies require you to pay for and use their own sensors. With ConnectSense, you are able to use any third party sensor with a dry contact output using a dry contact input device. There is also a 4-20mA solution as well.

CS-DryContact

10. Expandability

With home security companies, you have to call them to add more sensors, and schedule them to install them for you if you ever want to expand you service. This is costly and inconvenient. With cloud based solutions like ConnectSense you add sensors to your account and are able to manage them individually. Expansion is simple and cost nothing more than the cost of the hardware.

Read More [fa icon="long-arrow-right"]

MODBUS in a Nutshell

[fa icon='calendar'] Apr 11, 2013 5:09:55 PM / by Jonathan Witthoeft posted in General, modbus, modbus explained, modbus rtu, modbus tcp, modbus tutorial, modbus/tcp, Products

[fa icon="comment"] 0 Comments

MODBUS may seem complicated and confusing to some, but it is a very simple protocol when you understand how it works.  MODBUS is a request and response protocol.   A MODBUS master will initiate a request and a slave will respond with either an error or the data requested.  This is the simple concept of MODBUS.

You can implement MODBUS over several different types of busses and networks, but there is one core component of MODBUS protocol that is used in all of them.  This piece is referred to as the Protocol Data Unit (PDU).   When speaking of MODBUS in general, the PDU is the entirety of the protocol.  The PDU consist of a function code and data.

MODBUS can be used over nearly all busses and networks, however the most common two are Ethernet (TCP/IP) and Serial (RS232, RS485, RS422, etc.).  There are specifications for both MODBUS/TCP and MODBUS serial.  MODBUS/RTU is the most commonly used serial MODBUS protocol.  There is also a less common ASCII version.  The difference between MODBUS/TCP and MODBUS/RTU is mostly in the transport frames or the wrapper around the PDU.   In both forms of MODBUS, application specific addressing and error checking are attached to the PDU to make the Application Data Unit (ADU).  In MODBUS/TCP the ADU is encapsulated in a TCP packet.  The TCP protocol handles the error checking, which is why it is omitted from the MODBUS/TCP ADU.

 

 

MODBUS/RTU Serial – Slave ID and CRC

Slave ID - 1 byte.  Identifies which slave device receives the request.

CRC – 2 bytes.  Insures that the correct amount of bytes were sent and received.

MODBUS/TCP – MODBUS Application Protocol (MBAP)
Transaction Identifier - 2 bytes.  Helps identify each request/response pair when several responses are expected.

Protocol Identifier - 2 bytes.  For regular MODBUS protocol, it is set to 00 00.  Incorporated for protocol expansion in the future.

Length - 2 bytes.  Identifies the number of bytes in the message to follow.

Unit ID – 1 byte.  If a MODBUS/TCP gateway is used, there may be several slaves that use the same IP address.  The Unit ID is used to differentiate which slave the request is for.

There are four supported data tables for MODBUS devices.  These are Discrete Inputs, Discrete Outputs (Coils), Input Registers, and Holding Registers.  Each table can support up to 65536 data addresses.  They are addressed 0000 to FFFF hexadecimal (0 to 65535 decimal).  The data table is selected by the function code.  The data addresses on that table, for reading or writing, are specified by a start address (2 bytes) and a size (2 bytes) at the beginning of the data portion of the PDU.  Discrete Inputs are 1-bit and read-only.  Discrete Outputs (Coils) are 1-bit and read-write.  Input Registers are 16-bit and read-only.  Holding Registers are 16-bit and read-write.  The following illustrates the data model and addressing for MODBUS protocol.

Most GUIs try to make the adressing more user friendly.  They do this with 1 based addressing (starting at 1 rather than 0) and appending a number at the front of the address correlating to the data type.  Discrete Inputs append a 1, Discrete Outputs (Coils) append a 0, Input Registers append a 3, and Holding Registers append a 4.  The following illustrates addressing structure commonly used in MODBUS software.

In conclusion, MODBUS is simply a request and response protocol.  Requests consist of an ID to determine which unit to address, function codes to specify what is being requested, and data.  Responses use these same 3 fields to respond to the requests.  Different networks add different variations to the protocol, but they all address the same MODBUS data structure which has Discrete Inputs, Discrete Outputs (Coils), Input Registers, and Holding Registers.

Read More [fa icon="long-arrow-right"]

Serial Device Servers

[fa icon='calendar'] Jan 24, 2013 11:38:10 AM / by Jonathan Witthoeft posted in Device Server, Ethernet, General, NET232, NET485, Products, Serial, Serial to Ethernet, WI232

[fa icon="comment"] 0 Comments

Serial Device Servers transfer data between a serial port and an Ethernet network.  Some of the most common serial interfaces are RS232 (typically DB9) and RS485 (typically 2 wire).  The most common Ethernet protocol used in serial device servers is TCP/IP.  The NET232, for example, will take RS232 serial data from a 9 pin port, encapsulate it in a TCP packet, and send it on an Ethernet network from a configurable IP address and port number.  This makes it possible to use Ethernet in place of serial cables, which minimizes workstation clutter and also allows serial devices to be used beyond their typical limitations.

Ethernet protocols other than TCP/IP are supported by specialty device servers.  These include, but are not limited to, Modbus TCP to Modbus RTU (NET485-MB) and Ethernet/IP to Modbus RTU (NET485-EIP-MB) device servers.  These require special firmware due to the extra steps involved in not only adding another layer to the TCP protocol, but also adding a serial protocol for sending data across the serial interface.

Device servers make it possible to access distant serial devices as if they were directly connected to the COM port of a personal computer via the internet and virtual COM port software.  They can be used with all types of serial devices and peripherals such as printers, data collection terminals, modems, and automation equipment.   Device servers are available for hard-wired networks, like the NET232, and wireless networks, like the WI232.

Most serial protocols on RS485 allow for daisy chained serial devices.  This is due to the addressing that is in protocols, such as Modbus RTU, which allow serial devices on an RS485 network to only respond to messages addressed to them.  In this case one serial server can control multiple serial devices through address mapping.  The following illustration shows an example where one of our NET485 devices is used with several barcode scanners.

Read More [fa icon="long-arrow-right"]

Introducing the xPico – Smallest Device Server in the World

[fa icon='calendar'] May 16, 2012 11:02:18 AM / by Jonathan Witthoeft posted in chip, embedded, Ethernet, General, Press Releases, Products, RJ45, xPort, xPico

[fa icon="comment"] 0 Comments

 

xPico is a networking solution that enables Ethernet connectivity on any serial interface.  This little, chip sized xPico is the smallest embedded device server in the world.  It is a complete device server with a full IP stack and web server.  It supports serial data rates up to 921Kbps and has the same functionality and user interface of the xPort.

xPico has added versatility to the xPort by removing its RJ45 circuitry. The end user can now use custom circuitry and is not bound to the xPort’s hardware components. The xPico therefore supports POE circuitry and boards that already supply an RJ45 jack and magnetics.

 

The xPico starts at $25.00 and is available both as a module and in a development kit

Read More [fa icon="long-arrow-right"]

Application Adaptation - Creative Solutions for Customer Specific Applications

[fa icon='calendar'] May 10, 2012 11:00:19 AM / by Jonathan Witthoeft posted in Bluetooth, Custom, FireFly, Flow Control, General, Products, RS-232, Siemens, Technical Support

[fa icon="comment"] 0 Comments

“This product is NOT compatible with your application.” These are the dreaded words that no customer is glad to hear.  Not only were you looking forward to using the device, but now after built anticipation and empty hopes, you are told it will not work.  At Grid Connect  we try to avoid this statement at all costs.  Our technical sales advisory, expert technical support, and vast product versatility give us the tools to make our Bluetooth products work for you.

Recently a customer requested help using our firefly unit with a Siemens DDC.  The only problem was that this DDC required a loop back of hardware flow control pins CTS and RTS.  This is an option normally not supported.

End Device Flow Control Loop-Back

The flow control loop-back is a problem that is normally solved through a custom cable that would be in-between the firefly and the DDC controller.

This was not a possibility for the customer; the firefly needed to be directly plugged into the DDC.  So we tested and came up with a different solution.  We found that jumpering internal pins 6 and 7 of the firefly unit would directly loopback the RTS and CTS pins of the db9.  This is a solution within the firefly and no additional cables would be needed.

Since the jumpers will not fit in a diagonal orientation, we suggest using wire wrapping rather than soldering so not to void our one year warranty.

Content from:

Application Note - Using a Firefly with Siemens DDC Controllers

Read More [fa icon="long-arrow-right"]

The Future of Industrial Networking

[fa icon='calendar'] Dec 13, 2011 12:00:15 PM / by Jonathan Witthoeft posted in Ethernet, Featured In, General, gigabit ethernet, gridARM, industrial network, industrial networking, Jim Montague, microprocessors, Mike Justice, Products

[fa icon="comment"] 2 Comments

What is an industrial network driven on?   What will prepare a network for the future?  Microprocessors are the “Heart of the Network,” according to Jim Montague, executive editor at Putman Media.  “Heart of the Network,” featuring our own Mike Justice, is the featured publication in the fourth quarter 2011 edition of Industrial Networking.

Mike Justice stated, “Microprocessors might be on the lowest layer of the network, but they have a huge influence.”  Chips have evolved from simple standard microprocessors, to application-specific integrated circuits, field-programmable gate arrays, and so on.  Design flexibility is what allows industrial networking to move into the future.

gridARM System on a Chip

Gigabit Ethernet will help industrial networks keep up with the bandwidth requirements for increased network traffic.  Many gigabit products have already hit the commercial network.  It will not be long before the industrial Ethernet networks will need to speed up.  With our new gridARM microprocessor, we are able to supply our customers with a cheap Gigabit Ethernet solution for adding fast Ethernet to their devices.

The gridARM microprocessor is designed for low cost products that require a fast Ethernet connection.  This system on a chip is most flexible because it includes an ARM7TDMI core, 10/100/1000 Ethernet MAC, CAN controller, up to 3 serial ports, I2C, SPI, on chip SRAM, USB device, A/D converters, and interfaces for SDRAM, Flash, Compact Flash, external SRAM, and NAND flash.

To understand why the microprocessor is the underlying technology driving advances in industrial networks and to understand how you can benefit from the evolution of microprocessors, download the full “Heart of the Network” article below.

Read More [fa icon="long-arrow-right"]

10 Factors when deciding between Industrial and Consumer Networking Devices

[fa icon='calendar'] Oct 20, 2011 10:34:50 AM / by Jonathan Witthoeft posted in commercial, Consumer, General, Industrial, Industrial Switch, Industrial Switches, Routers, Switches, White Papers

[fa icon="comment"] 0 Comments

1.  Protection against solid foreign objects

What solid foreign objects are a part of your operational atmosphere?  Will your device need to be dust tight, protected against wires, or not protected at all?  If maintenance is not an option due to distance or inaccessibility, then you might need to consider what objects can find their way into your devices enclosure.

2.  Protection against water

This is very important in an outdoor application.  You want your device to be able to withstand rain.  Also what if you need your device to be submerged in water, or need to be able to hose down the device when cleaning an industrial area?  These are all conditions that need to be considered when determining which device to go with.

3.  Protection against oil, coolant, and corrosive agents

Hazardous materials can limit the range of products applicable for use.  Without a doubt, you need to have an industrial product for protection against oil, coolant, and other corrosive agents that might be in that operational atmosphere.

4.  Temperature range

There are typically two temperature ranges to consider in the specifications of a product: operational temperature and storage temperature.  Industrial products tend to have wider ranges for both of these.  If you need to store or use a device in an extreme temperature, you would want to use an industrial device.

5.  Durability

Some applications require a tolerance for impact or fast motion.  Some tests that are done on industrial devices include stationary vibration, shock, and vertical free-fall.  Some devices are also given an impact rating from 0 to 20.0 Joules.

6.  Surge protection

Surge protection ratings specify the protection level electrical devices have from voltage spikes.  In certain conditions components need to be able to withstand large spikes in voltage.  Industrial devices tend to have a higher range of tolerable AC and DC voltage spikes.

7.  Electromagnetic response

In many applications multiple electronics are in the same confined area.  Some of which might have motors, or other components that create EMF.  It is important, in this case, that your device can tolerate different electromagnetic conditions.  Industrial devices have higher electromagnetic resistance than consumer devices.

8.  Power supply

Consumer products are usually powered with a wall plug.  Industrial products are often powered in parallel to each other.  They share power supplies, rather than having a dedicated power supply for each unit.  Some have redundant power inputs that are used with redundant power supplies.

9.  Enclosure mounting

Many consumer devices are designed to be set on a desk or other flat surface and do not include any mounting options.  Industrial products include mounting options such as DIN Rail Mounting and Panel Mounting.

10.  Longevity

Most industrial products in an industrial application would be functional approximately 3 to 5 times longer than a consumer device in normal IT application.

Read More [fa icon="long-arrow-right"]

Routers and Switches and Hubs…Oh My!

[fa icon='calendar'] Sep 12, 2011 5:04:32 PM / by Jonathan Witthoeft posted in General, Hubs, Industrial Switch, Industrial Switches, Products, Routers, Switches

[fa icon="comment"] 1 Comment

EKI-2728-BE Industrial Gigabit Switch 8 Port Industrial Gigabit Switch

Hubs, switches, and routers are all the same in the sense of connecting network devices with each other at one of three speeds.  Most devices are capable of both 10Mbs and 100Mbs and will automatically detect the speed.  If the device is only capable with one speed then it will only be able to communicate with switches that also support that speed.  Gigabit devices (1Gbs) are starting to slowly become more common as well.  Gigabit switches, e.g. our GC-EKI-2728-BE, can be used with these devices to utilize that faster speed.

Speed aside, there are still key differences between routers, switches, and hubs that many people are confused about.  I often see people misusing these titles and would like to clear this up.  I will start with the least complicated.

A Hub is the cheapest option of the three.  They are not intelligent and they simply forward all communication that is received on one port out to all of the remaining ports.  All of the devices connected to a hub can see all of the data sent through it.  The hub does nothing with the data being transmitted.  Hubs are great in small networks without a lot of traffic.

ATC 405 Industrial Managed Switch 5 Port Industrial Managed Switch

A Switch does a little more.  A switch is intelligent.  Switches recognize what devices are on what ports by analyzing that ports traffic.  It is able to determine which particular addresses are associated with which particular ports.  For example, if it sees traffic from my PC coming in on port 1, it will send all traffic for my PC to port 1 and not any of the other ports.  With switches, most of the network traffic only goes where it needs to rather than to every port.  On larger, busy networks this will increase the network speed.  Managed switches, like our GC-ATC-405, have their own IP address and have configurable options such as directing traffic to certain ports or ignoring traffic of a certain protocol.

A Router is the most intelligent of the three. A router is a Layer 3 gateway, which means it operates at the network layer of the OSI model.  It routes traffic from one network to another.  It has the same functionality as a switch and a hub, but also does much more.  A router is programmed to understand, possibly manipulate, and route the data it’s given.    Most routers include the ability to hide devices behind a firewall as well as all of the functionality found in a managed switch.  With the use of a routing table, routers have the ability to filter traffic, either incoming or outgoing, based on the IP addresses of senders and receivers.  The entire configuration is done through some kind of user interface, e.g., a web page.

Read More [fa icon="long-arrow-right"]

Subscribe to Email Updates

Lists by Topic

see all