Automation Programming Introduction

Just a bit of an update after a long period of inactivity from blogging. A lot of people have been asking me to blog about my experience with automation and IoT. It’s a rather large topic which is most likely why I’ve been putting off writing about it for a while, but it’s so much more than just relays and having things connected by the internet.

If you’re talking about automation in itself, it doesn’t necessarily inherently mean you’re dealing with IoT but they can be related in a way if your device can communicate over ethernet in some way. HTTP(S) seems to be the most popular choice because this way the communication can be platform-independent, especially if the device has a webserver built in and you can interact with the device through an API – lots of devices choose to implement RESTful API’s from my findings as it’s a rather simple yet extensible approach.

Even if the devices you’re talking to from some kind of controller aren’t internet connected there’s tons of protocols that you may need to know about, before even considering the hardware required to interact with a specific device. From my experience, if you need to use some kind of serial communication protocol there’s RS-232, RS-422, RS-485, but RS-232 being the most common unless you need longer distances or other functionality requirements. For lights, I know there’s the Philips Hue system which involves IP (TCP) communication, and ZigBee which is handled by the hub as a protocol to deal with communication to and from the bulbs back to the hub as an RF type of protocol similar to WiFi and Bluetooth, but lower bandwidth than WiFi. Other commercial grade lighting protocols may use things like RadioRa2 or even DMX-512, both of which I’ve dealt with in various cases. In addition to Bluetooth as a common consumer-level protocol, there’s also IR as a communication type for pretty much most devices you can think of (TV’s, etc…) but if you require feedback you’re out of luck without some other kind of hardware for power-sensing or anything similar since it’s a one way communication type. If you can’t use IR, most people don’t know that HDMI has CEC which would enable you to control a TV or a receiver for instance in your home entertainment system, and although it’s convenient, the problem is that it’s frequently poorly implemented by hardware manufacturers which makes it less reliable for anything past the most basic commands (power on/off for example). An example of this was for turning an Apple TV back on after it went into sleep mode: IR worked, but CEC did not. My best guess for why this is, is that the Apple TV remote is required to work because it’s used more often than CEC control by end-users, so hardware manufacturers don’t spend enough time fully testing device control for people who are interested in controlling devices in less-common ways. If that’s not the answer then it has to do with energy saving ratings, where I know TV’s in particular will turn USB port power, and RS-232C ports off in certain modes unless you change the settings in the TV to tell it not to do that. This makes things rather difficult for us automation programmers because less things are standardized than what we would like to think. In particular, some Sharp displays require you to send an RSPW command to enable IP or RS-232 control for power on, so if the TV is not already on, and you don’t send this command before powering the display off, you’ll never be able to turn the monitor back on. Other displays that have serial ports for control do not require you to do this but you must change some of the settings in the TV to enable control. Device firmware also changes quite a lot of things. What makes things worse is when particular manufacturers (such as Samsung) implement their own proprietary version of protocols (ExLink for instance).

It would be nice to have things more standardized, but the problem with automation today with common household and commercial equipment is that nobody has a standard to go by, and things change too fast for everyone to get on the same boat before it leaves the dock! Lots of people don’t know that HDMI 1.4 in addition to supporting 4K, also has the capability to support ethernet, and although that’s cool, I think HDBaseT is much more useful and feature packed, so it never took off. Personally I’ve never seen a device that supports stripping the ethernet communication off an HDMI connector or uses that instead of an RJ-45 port for ethernet.

In summary, I think the whole reason why I’ve been asked so many times to write about automation and IoT is that the underlying requirements change too fast for most people to get a handle on how things really work, and unless it’s your career like it is mine, then you’ll have a harder time keeping up with how fast technology and protocols change.

I’m going to try and blog a bit more though! Keep posted.

No Comments

Unique String Encoding With Bitwise Operations

Here is a method for encoding a string that I came up with. It is actually a fairly nice method, the strategy behind this and the idea can be added onto, but this works quite well the way it is right now and for how random the output looks when we encode the original string value.

const string originalObj = "Let’s have ourselves a Fiesta!!!";
Console.WriteLine("Original: {0}", originalObj);
Console.WriteLine("——————-");

// Encoding

char* objEncode = stackalloc char[originalObj.Length];
for (int i = 0; i < originalObj.Length; i++)
{
	int j = originalObj[i] ^ i + 1;
	objEncode[i] = (char)j;
}

string encodedObj = new string(objEncode);
Console.WriteLine("Encoded: {0}", encodedObj);

// Decoding

char* objDecode = stackalloc char[encodedObj.Length];
for (int i = 0; i < encodedObj.Length; i++)
{
	int j = encodedObj[i] ^ i + 1;
	objDecode[i] = (char)j;
}

string decodedObj = new string(objDecode);
Console.WriteLine("Decoded: {0}", decodedObj);

This snippet has to run in unsafe context.

Perhaps you could also use the reversed index over some constant value as well to get a more unique and refined result... Just as a reminder, we are using the stack here, not the heap, so that is just something to remember.

, ,

No Comments