Author Archives: Vetinari

Moving CloudApp MySQL WordPress database on Azure to “MySQL in App”

Some of Azure WordPress users found out that CloudApp MySQL database, which was ~1 year ago a default one, is not longer supported. There are two new possibilites though, one is “Azure Database for MySQL” which is quite expensive for small website, and “MySQL in App” which fits just fine.

The migration is quite stragihtforward. First log in to Azure management console and find your application:

Then enable “MySQL in App”:

Then open your website (to trigger mysql process start, might not be necessary, but for me it was) and open “Advanced Tools” from your application settings (still Azure management dashboard):

Select CMD from top menu:

Navigate to “d:\home\data\mysql” and expand the list using the

arrow. Then open “MYSQLCONNSTR_localdb.txt” file (using edit button on the left):

Copy the content, open the “Application Settings” from Azure application management and find “Connection strings”. Update the value using the data from “MYSQLCONNSTR_localdb.txt” file, sometimes it is required to first check the checkbox on the right.

Last but not least you need to import the previous database from the file. Select “MySQL in App from the menu and click “Manage” button on the top. This will open the phpMyAdmin.

Default database is “localdb” and it can be safely used, but if you for some reason want to use a different databse just remember to update the connection string in “Application Settings”.

Now the page should be back online.

Returning array of C++ wrapped objects to NodeJS and JavaScript using nan

Lately I had a hard time trying to figure out how to properly wrap simple C++ objects (like structs or so) with limited understanding of object-oriented JS. So I took some time (actually not so long, but sill) and found out that there are no classes in JS so constructing objects is quite tricky as it always use prototype function.

Don’t really like the idea, but well…

Anyway, it was not really straightforward at the beginning to wrap C++ object. A bit easier after figuring out all that function for objects creation. It ends up with creating new wrapping object that has a creating function (I have called it “constructor” using the same naming as in the documentation. My objects are read only (in fact it is a representation of serial devices) and all properties are also read only, so I had to create only getters, called accessors:

So the whole “constructor” template function looks like this:

Then for each getter you can create a method (I liked this way) or create one getter and use the name to distinguish return values. For me it looked like this:

So the last thing is to create the JS object from the C++ object and fill the array. First object creation:

When we do have this we just need to create an JavaScript array with nan and v8:

That’s all, final result looks like this in console:

As always you can see the whole code as a commit on the github:

After finally resolving this problems it is time to go on with UART communication and sending some commands to ELM327 😉

Logs panel in Electron and C++ addon

Today I have decided that I need to have a try in merging what I have done in C++ with Electron and JS (and NodeJS) as my prototype lacks currently of any GUI.

The first thing will be most important in my opinion, as I will probably use it later all the time. Let me introduce you logs panel:

It displays all logs messages received from both my addons. Those messages are going to be logged to file (or console) too, but I do like to have them visible in application too for easier debugging.

This is especially important considering that all (or some) of OBD2 communication will be logged here, so I can actually see what is going on with the interface when I try out the buttons without leaving the app window. Later it will be detachable, currently it is enough for me to filter messages by log level.

Actually quite easy to do, the only thing that was important for me was adding jQuery:

Usage is pretty straightforward too:

That’s all for now, next thing might be serial communication 😉

macOS serial devices enumeration and recognition with IOKit

As promised earlier today I will show how serial (or any kind of devices) can be enumerated using IOKit. As currently MacBooks don’t have serial port and most of serial devices are connected using USB or Bluetooth I will also show how can we access informations about what kind of device shares the serial protocol and is visible in /dev.

The easiest way (which I won’t use) is to list tty* devices in dev:

ls /dev/tty*

It is clearly visible that we don’t have a lot of informations about the device, it is limited to the name which may indicate even a disconnected device (for Bluetooth). Also there are virtual devices which are useless for me.

Fortunately Apple has a documentation for serial devices enumeration using IOKit:

So we can create a simple method to enumerate devices:

We enumerate serial devices using flag kIOSerialBSDServiceValue and the device path that we can use is held in kIOCalloutDeviceKey.

I had to create helpers to get string for key and convert to std::string :

This way we do properly have a list of serial devices to connect, but not the information about which connected (or internal) devices are described by the path.

We can see this using ioreg -l  command:

Devices are visible in a tree manner, just like a filesystem directories, and two levels up there is a node of type IOBluetoothSerialClient which has a lot of useful information about the device. The same works for  IOUSBDevice  class.

So we can see that the data is available and seems similar to enumeration we done before. Maybe we can go up level by level using “parent” value and check for this classes?

Indeed we can. In fact there is even a specific function for that:

Which can be used in similar fashion to previous enumeration:

The whole class is available here:

The logger which I use is also part of the project:

That’s all for this post, I hope you will find this useful 😉

Abstracting serial device from an OS layer

Today a bit about serial communication as it will be a base communication layer ELM327 and CAN communication, just like IP is a base layer for TCP/UDP.

Why abstraction though? Application is currently for OS X so this is not really a must have. On the other hand this is how it usually should be done, especially if we consider multiplatform in the future. This is also not a really big change big difference too and makes code a bit cleaner.

So what do we need? Shortly: a common interface and common types for all parameters and return values. I divided it into two parts, may be the same library finally, but can be also easily split in two. Just the matter of preference. It is:

  • Serial devices enumeration and recognition.
  • Serial device access: open, read, write, close with parameters as baud rate, parity control etc.

First thing is a really OS specific thing, but interestingly quite easy to create an interface. I made a decision to support both Bluetooth and USB serial adapters and tested it with:

Enumeration will be explained in next post, now just an interface:

Easy to use, one method that returns a list of SerialDevice objects that describes serial port and parent objects that describes a specific device that handles serial communication: USB. Bluetooth or Other, unknown device type.

For USB and Bluetooth devices I try to get more specific information about name, vendor etc.

Current implementation is here:

Later on I’ve opened the man page for open(): x-man-page://2/open  and made some assumptions for possible errors and parameters:

Man page for open() in Terminal

Next thing, which is currently in progress, is device access and read write. The interface will be much more complicated, as it has to support a lot of open() flags, configuration parameters and errors,

First thing to notice is that we have specific errors in enum, but SerialOpenFlag is a bitmask, so it had to be implemented with consecutive powers of 2: 0x0001, 0x0002, 0x0004, 0x0008… so in a result we might set any bit of the flag without affecting other ones – READ_WRITE and NOBLOCK is for example b’00001100′.

On the other hand the interface cannot be platform specific, so we have to map this later to system specific codes, I decided for it to look like this:

Similar way for error handling for open() operation:

Easy to maintain, easily readable and extendable. Moreover, totally abstract from the OS specific functions 😉

Next post will be about macOS serial devices enumeration and recognition, stay tuned 😉

Dive into an OBD2 world with ELM327

Today we are going to have a bit of introduction to what the OBD2 and ELM327 is, protocols and trouble codes. This is necessary to understand what we are going to do later on.

First a dictionary:

OBD / OBD2 – OBD2 is the second version of connector that is available in all modern cars and connects to CAN bus or ECU of the car. We will use only protocols compliant with OBD2 connector, OBD is an old version to which OBD2 is not backwards compatible.
CAN – Controller Area Network, serial bus that allows car components to communicate with ECU.
DTC – Diagnostic Trouble Codes.
PIDS – Parameter IDs for CAN requests.

I am going to use ELM327 controller (or Chinese counterfeit). It is quite cheap and easy to buy and does support a lot of protocols:

0 – Automatic
1 – SAE J1850 PWM (41.6 kbaud)
2 – SAE J1850 VPW (10.4 kbaud)
3 – ISO 9141-2 (5 baud init, 10.4 kbaud)
4 – ISO 14230-4 KWP (5 baud init, 10.4 kbaud)
5 – ISO 14230-4 KWP (fast init, 10.4 kbaud)
6 – ISO 15765-4 CAN (11 bit ID, 500 kbaud)
7 – ISO 15765-4 CAN (29 bit ID, 500 kbaud)
8 – ISO 15765-4 CAN (11 bit ID, 250 kbaud)
9 – ISO 15765-4 CAN (29 bit ID, 250 kbaud)
A – SAE J1939 CAN (29 bit ID, 250* kbaud)
B – USER1 CAN (11* bit ID, 125* kbaud)
C – USER2 CAN (11* bit ID, 50* kbaud)

Modern cars usually have CAN connection, older ones may have a different protocol. Luckily there is automatic connection available in ELM which tries all the protocols and selects the working one (I assume this is the first that responded for the request).

User can communicate with ELM327 using AT commands, popular in modems communication. The specific subset depends on the controller version. There is a good breakdown of commands supported in each version in the table:

The description and usage for each command is available in the datasheet for ELM372. There is also an indication for which protocol it is available which may come in handy:

Next thing are “Diagnostic Error Codes”, usually connected with “Check Engine” light:

Check engine lights.







This generally indicates current (or possible in  the future) problem with one or more parts of the engine. I have merged some data available on the internet for quick reference of trouble codes:

More or less complete list of DTC codes is available here:

There is much more data available on wiki about the OBD2 in general which might be useful later:

That’s all for now as it gets quite long. Stay tuned 😉

Opel Corsa D Diagnostic Mode (Test Mode)

Just a quick update. During of OBD2 connection test I have found a possibility to enter test mode in the car where I can validate results using values that trip computer receives from ECU – yay! Even though my car does not have trip computer 😀

Press km reset button four times and hold it at fourth time for 10 seconds (or just until screen changes). There will be a few screens (selectable with the same button):

  1. Car production version and date.
  2. Firmware production version and date.
  3. ???
  4. Vehicle speed and engine RPMs.
  5. Battery voltage and status.
  6. Dashboard backlight level (0-100) and coolant temperature.
  7. ??? (100 / L2 XXX)
  8. ??? (100 / S2 XXX)
  9. ??? (100 / P2 XXX)
  10. ??? (100 / t2 XXX)
  11. Fuel level in liters and remaining distance. – I don’t know what is in the second line, maybe short and long term trim?
  12. Fuel flow and fuel economy.
  13. Days and distance from reseting inspection.

What’s inside the chinese ELM327 USB


I had to buy a few ELM327 with USB cable for different project. I have no use for USB cable as it is in the module, but I hope there is UART and kinda liked the idea of just stripping out the USB cable and replacing with the other one without changing the case.

This is it:

And without the label:

Under the label.

Screw holes, nice. But no screws inside 🙁 Just melted PCV. Well, let’s open it anyway, maybe I am missing something:

Opening the case the hard way.

With a bit of force it worked. Here is what’s inside:


Small chip (8 legs, one floating) is the NV342-0 which is CAN transceiver (Vsplit is N/C):

In the second picture a soldered on the top board has 12kHz oscilator and PL-2303HX – UART to USB converter (Prolific one).

The main controller is probably under the black blob in the middle. And the cable cannot be disconnected without desoldering.

I am actually really surprised with this, it seems to be multi-layer PCB (more than two layers for sure) with a BGA chip. Quite well engineered, maybe not so well done (handmade :D), but still, better than I predicted for the price.

NodeJS addon with C++ and Objective-C

I have finished the module a few days ago (and it does not work, check the previous post) so now it is a good time to show a bit of technical difficulties and solutions.

First things first – an introduction. What we want is a class (I think in JS more proper name is a  prototype) with a few methods:

  • StartScan – with callback for results.
  • StopScan
  • IsScanning
  • GetState – current state of bluetooth (on/off etc).

We start with a module file –, structure of binding.gyp was described before for that project so I won’t paste it again, this is the file:

I used nan as the whole internet recommended and ended with something like this:

Let’s divide it into parts and describe one by one. First we need a module to export information and module initialization information. First says what we want to export and second is a static function that creates that object:

We use two defines to achieve this – NODE_MODULE  with two parameters: module name and second is initialization function conveniently declared by macro NAN_MODULE_INIT  with one parameter – a name. We export here a class and a function – we don’t have to export just a one thing.

Then we need a class to export – let’s call it Cougar_Bluetooth and init from inside of Init – this is visible in the snippet above. Next create a class:

There  static NAN_MODULE_INIT(Init) method which initializes class by setting a class name with

and constructor (the “new” method) with:

Of course we need methods inside the class too:

Method static NAN_METHOD(New) is our constructor, but in JavaScript we have to take care also for the possibility of using the constructor without the new operator – we just call the constructor with provided arguments in that case. Also we have a static field to hold that constructor. There we use a trick to avoid initialization in another file – we don’t need this if it is static variable in static method, so we return a reference to that object:

Last but not least I will show you how we can create a method in the class, this time descriptions will be inline in code:

That’s all. I have tested callback with simple logger class (to log messages from the addon to JS console) and it works. There were no callback calls for scan, because my devices are not BLE.

Seems quite easy at this point, but believe me – it wasn’t. At least it is not when you don’t have a code that you can copy and paste or clone.

CoreBluetooth and bluetooth devices enumeration on OS X

So ending our adventure with first module – bluetooth devices enumeration I have bad news. OS X does not support programatically enumeration of generic Bluetooth devices. There is CoreBluetooth, but it works only with BLE (Bluetooth Low Energy). There is the GameKit, but it only works if you want to pair two or more devices with specified service type – in most cases iPhone with Mac. I wanted something like this:

So we have now a module that enumerates BLE devices nearby. And ELM327 is not a BLE device. GREAT 😀

Anyway, I have learned a lot about what is not possible and a lot about what is not. For new it will be enough to tell user to just connect the device before use. Whole prototype project is in this commit:

In directory prototypes. Next article (soon) will be more technical about module developement based on cougar_bluetooth_lib module.