Controlling Mobius enabled VorTech pump using 0-10V (and BLE)

[mard]

In my pursuit to trigger feed and maintenance modes using a single push button, I have come across a few challenges. Sure I have a Profilux 4 controller which handles most of my pumps and such. And my plans include connecting some buttons to trigger the modes (likely something from Harry's Aquatics as shown here). However my VorTech MP40 pump which is controlled by the Mobius app or its own controller doesn't (yet) play well with others.

Hypothesis:​

A Mobius controlled VorTech pump can be controlled using a 0-10V interface.

Ok so that is a simple enough hypothesis and the solution will be a bit more complicated. But here was my thought process.
If (a) the BLE (Bluetooth Low Energy) messages being sent to the VorTech pump from the Mobius app can be captured, and (b) a DIY device controlled with a 0-10V interface can send BLE messages, then (c) the VorTech pump can be controlled with a 0-10V interface.
(a) + (b) = (c) Right?

(a) Capturing BLE Messages​

Sniffing Bluetooth traffic can be done in a couple different ways. The easiest and most convenient way is having the device (phone or tablet) which sends the messages to also log the traffic. Android devices have such a feature. Enabling Developer mode on an Android device provides the "Bluetooth HCI snoop log" option. Once the logging option is enabled simply use the Mobius app to turn on/off different "Scenes". I started very simple and noted when a scene was started and stopped.

Once the btsnoop_hci.log is produced it can be opened with Wireshark on a computer. Without any filtering Wireshark will show all of the captured messages. This could be hundreds if not thousands of messages. So finding out which messages are meant for the VorTech controller is crucial. Luckily there is an app for that.

The nRF Connect app is great for discovering and testing different BLE devices. Scanning with the app will find all nearby devices. When I filtered for a "mobius" device it resulted in the following:

This shows that my Mobius device has an address of DC:53:84:AB:5D:4B. This piece of information will help drastically reduce the number of relevant messages in the log. Back in Wireshark a filter can be created to only show Bluetooth messages addressing the Mobius device so both sent and received messages are viewable.

The last thing I did before turning off Bluetooth (thus stopped collecting messages) was to start a scene for ~20 seconds and then stop it. This allowed me to scroll to the bottom of the filtered logs and start working backwards to see what was actually sent. And sure enough, there were two messages sent from my device to the Mobius device ~20 seconds apart.

And there it is. The value (in my case 02de180c0008000900910100010401000000f6b1) which appears to start the feed scene. It also shows which BLE service UUID and characteristic UUID the message it was sent to. The nRF Connect app now can be used to test the BLE message. Once connected to the Mobius device through the nRF Connect app, a list of available unknown services will be displayed. Once the corresponding characteristic is found using the UUIDs, the app can also attempt to send messages to the characteristic.

Ta-da! When the same value is sent to the same characteristic using the nRF Connect app the VorTech pump starts the feed scene. The same is true for stopping the scene (which was the value sent ~20 seconds after the start value in the logs). This is enough to prove the BLE messages sent to VorTech pumps can be spoofed/mimicked/replicated.

More investigation will show the value being sent by the Mobius app changes slightly every time even though the scene doesn't change. Of course this piqued my curiosity and I started to deduce their meanings. So far I've identified a few parts for a couple difference messages. But I will provide what I have found in a separate following post.

There are many helpful write-ups about this sort of effort online. Just search for something like "reverse engineering bluetooth" and read through a couple.

(b) Send BLE Messages Based on 0-10V Input​

There are a few available options which are capable of sending BLE messages and able to read analog signals. While a Raspberry Pi device was my second choice, I decided to use an Arduino Nano 33 BLE because they have an ADC (Analog to Digital Converter) built-in. They can also be powered by a button/coin battery which is something I eventually want.

The ADC is needed to take 0-10V input signals and give them a digital value. However, similar to many other microcontrollers, the Arduino Nano 33 BLE can't handle a full 10V signal. So a simple voltage divider needs to be added to drop the input signal down to 0-3V before it gets to the analog pin.

With the voltage divider in place some simple code for the Arduino will allow the board to do different things for different input signals. For my proof of concept I chose to do nothing until the input signal was equivalent to 4V or higher (simple math allows the digital value to represent 0-10V so the programming logic can match the original signal value).

The ArduinoBLE library can be used to find & connect a device, find the characteristic on the device, and write a value to that characteristic. So using the values captured during part (a) of this effort, a simple Arduino program can be written to do just that for the VorTech pump when triggered by the input signal.

(c) Controlling a VorTech Pump​

After a few trial and error attempts (with some additional Arduino debugging/logging), I was indeed able to activate a feed scene on my VorTech pump when I supplied over 4V as input to the Arduino board. Now the VorTech pump can still be managed by the Mobius app AND the feed scene can be triggered by my Profilux 4 controller.
Success! ;Woot

As a proof of concept this worked for a single Mobius scene with a single pump. However, I believe it would also work for multiple Mobius scenes and is not limited to just pumps. That's right. This technique should also work for any of the Mobius enabled devices which use BLE to communicate to the Mobius app.

Future Work​

While my simple program worked to trigger a feed scene once, I intend on enhancing it to be more robust and support all my controlling desires (e.g. triggering different scenes based on different input signals, and be able to identify the current scene being run). This will require more BLE sniffing to try and identify patterns and thus the actual Mobius API. Along the way I also plan on creating an Arduino library so other reefers can controller their Mobius devices with simple Arduino programs of their own.

 

[mard]

As promised above, here are some of the message patterns which I have deciphered so far.
(Disclaimer: these are based on only my captured logs between the Mobius app on my tablet to the single VorTech pump on my tank)

There are two BLE characteristics which play a role. First is what I'm considering the request channel characteristic because it is where messages are sent to the Mobius device from the tablet. This is "01ff0104ba5ef4ee5ca1eb1e5e4b1ce0" as seen/used in the proof of concept above.
In the request messages the first 4 bytes (if not the first 7 bytes) are fairly predictable. I've been considering the first 3 bytes as the "type" of message. Where the value "02de17" is something like a status request and "02de18" is more of an action request. The 4th byte seems to just be the message number, where the first message starts at 0 and each message after increases by 1. The last 2 bytes of every message appears to be some sort of hash or a checksum value. This leaves the bytes in between the first 4 bytes and the last 2 bytes as message specific.

Another characteristic to be aware of is "01ff0102ba5ef4ee5ca1eb1e5e4b1ce0". I'm considering this to be the response channel because it contains messages sent from the Mobius device to the listening tablet. Also these messages seem to have some identical bytes so the listener can match it with the request it sent. For example the first 4 bytes of a response message will match the first 4 bytes of the request message sent just prior. As with the request messages, the last 2 bytes are again some sort of hash or checksum value for the message.


Let's start with some simpler examples.
Here is an example of an action request to start the default feed scene (spaces and dashes added to help readability).
02de18 - 0c - 000800 09 009101000104 - 0100 - 0000 - f6b1
As predicted the first 3 bytes are what I call the "action" type and the 4th byte identifies itself as the 12th message. Bytes 15 & 16 are the scene ID (in this case 0100 as the default feed scene). I've also noticed that bytes 9 - 14 ("009101000104") seem to be an identifier of some sort for my pump. The last 2 bytes are some hash/checksum and the 2 bytes before that always seem to be 0.

So what does the VorTech pump respond with? A simple "success" message I think.
02df18 - 0c - 000000030000ffff - 6e5f
The first 4 bytes match the request message (message type and message number). And the next 8 bytes (000000030000ffff) are what I have been calling "successful". Of course the last 2 bytes are some hash/checksum again.

What if we wanted to cancel the current scene and have the pump go back to its normal schedule? Well that message would look like this:
02de18 - 0d - 000800 0600680000010103 - 0f57
Again the first 3 bytes are the "action" type and the 4th byte identifies as the 13th message. Besides the last 2 bytes as a hash/checksum, I haven't been able to discern much.

Can you guess what the VorTech pump responds with this time?
02df18 - 0d - 000000030000ffff - 4db4
Yeah, the first 4 bytes match the request message with a "successful" middle value followed by the infamous hash/checksum.


Now let's take a look at some bigger messages.
The following seems to be a sort of "status" request message (spaces added to help readability).
02de17 0a 000000 1400970100019101000196010001930100016b000001 b16c
Here the first 3 bytes are "02de17" indicating what I call a "status" type. The 4th byte is identifying itself as the 10th message sent.

That request prompted my VorTech pump to respond with (spaces added to help readability):
02df17 0a 000000 49000097010001250400000000000000000000000000000000000000000000000 1 2c01 000000000000000000 009101000104 0000 0 000 960100010200009301000102 00 006b000001020300 18bf
Ok that is a lot. But the first 7 bytes do match the request message. Again notice the "009101000104" as some sort of identifier for my pump. And the 2 bytes immediately following that ID is the scene ID currently running (in this case 0000 indicates the normal scene/schedule).


Again, these are all based on my Mobius scenes with a single VorTech pump. I am interested in seeing other hci.logs with multiple VorTech pumps, or even other Modius devices. But I will either need some volunteers to help provide logs or deeper pockets to purchase more EcoTech gear.

Of course, none of this crazy reverse engineering would be necessary if the Mobius BLE API was publicly available.

 

[MikeTheNewbie]

Hey, Mard kudos for the extensive reverse engineering and documentation work. How exciting!
I planned to start a similar project and posted that some time ago but got busy and distracted.
I'd be happy to collaborate!
I also started reverse engineering the Radions Mobius save file. And found some clues like the encoding, offsets for each color, and the transfer function for most of the colors. In the end it was easier to collect all the possible values and build a lookup table.
At this point I can define the whole schedule with all colors, intensities, times, and other features like clouds and storms.
Not sure how much they reused for Bluetooth but it might be worth sharing.

 

[MikeTheNewbie]

Here is the post I was referring to:
Thread 'Found a way to control Radion G5s (mobius) with Apex?' https://www.reef2reef.com/threads/found-a-way-to-control-radion-g5s-mobius-with-apex.796685/
@garbled might be interested in joining the effort too...

 

[mard]

@MikeTheNewbie that would be great! I'm not yet familiar with the Radions Mobius save file, but I'm sure we will see some similarities.

Looking forward to collaborating!

 

[garbled]

Some quick thoughts, and awesome work btw!

You might be able to use something like an i2c ADC to read the higher voltages. I use an ADS1115 in a bunch of my projects.. I can't remember if that particular chip reads above 6v or not though..

Have you been able to decode the checksum? If not, you can brute force a checksum alg with:
pycrc v0.9, https://pycrc.org

Very cool stuff!

 

[mard]

Thanks garbled!

So far my "inline" voltage divider has been sufficient for what I have been doing. It looks like the ADS1115 might have an absolute max of 7V though.

I haven't spent too much time tying to decode the checksum yet. In fact I don't even know if it is a checksum, that was just my assumption. But I will definitely try the pycrc soon. Thanks for the tips!

 

[garbled]

The pycrc thing works. It's a total pain, but it works. You basically need a large pile of messages, and then you feed it the whole mess, and it cracks the checksum. It's more likely they use on of the standard ones, so you might just try a few of those first. pycrc is for the super-crazy ones.

Yeah, figured the ADS was 7v max.. I swear there is another one that does up to 30v though.. can't recall offhand.

 

[mard]

Well I don't think the last 2 bytes are a CRC. I've tired both buteforce-crc and RevEng with no success.

If anyone is interested, I've been using the small "success" messages as inputs.

02df180c000000030000ffff6e5f
02df180d000000030000ffff4db4
02df180e000000030000ffff0999
02df180f000000030000ffff2a72
02df1810000000030000ffff80b9
02df1811000000030000ffffa352
02df1812000000030000ffffe77f
02df1813000000030000ffffc494
02df1814000000030000ffff6f25

 

[garbled]

One possibility when cracking CRC's, is that you don't know what the "payload" that is protected by the CRC is. For example from another project I worked on:

0A08ffffffffffffffffff320E

0A was the "start message" 0E was the "end message" 32 was the CRC, but the CRC only covered the 08fffffffffff part. So I would try different sections of the data through the various engines, just to see if something different happens...

Also I think you need to knock off the portion you think *is* the CRC. for example, if it's the 635f, you don't want to run that through the CRC cracker, just the part up to that. But it could also be just the 5f? Maybe the 02df is crc protected, maybe it's not? maybe just 02?

Just some thoughts. I ended up spending quite a long time dissecting the data and running it through over and over before I found mine.

Given this is a wireless protocol, I would find it strange if it didn't use CRC. That's not to say they might not use it, but...

One other thought, if there is an android app that can talk to the device via BT, grab the apk and run it through a java decompiler. The code will likely be unreadable, but you might be able to find something that helps decode some of the fields, or at least finds the separators.

 

[MikeTheNewbie]

So here is what I know about the mobius Radion save file:
First an example

UV

Violet

Royal

Blue

Cyan

Lime

Red

Moon Light

Moon Light Blue

Cool White

Intensity

Clouds

Storms

Data

0​

0​

0​

0​

0​

0​

0​

0​

0​

0​

100​

0​

0​

​

​

FQAAFwAAEgAAEQAAIQAAIgAAFAAAHwAAIAAAEAAAAegDZQAAZAAA

100​

100​

100​

100​

0​

0​

0​

0​

0​

0​

50​

0​

0​

​

​

FegDF+gDEugDEegDIQAAIgAAFAAAHwAAIAAAEAAAAfQBZQAAZAAA

100​

100​

100​

100​

100​

100​

100​

0​

0​

100​

100​

0​

0​

​

​

FegDF+gDEugDEegDIegDIugDFOgDHwAAIAAAEOgDAegDZQAAZAAA

The "Data" column is what Mobius saves in the .mob file. The columns on the left are the settings that produce each sequence.

1. They use Base64 encoding (A...Za...z0...9+/)
2. They use 3 characters to encode each color
3. Every color is separated by a fixed character
   • Example UV is the first value in the sequence and it is delimited by F and F. QAA = 0, egD = 100.
   • Royal is the 3rd value and it is delimited by E and E. gAA = 0, ugD =100.
4. Some colors use the same encoding. e.g. UV, Cyan, Intensity.
5. Now for the interesting part. Each color uses 3 characters. The rightmost character is the most significant and the center character is the least significant.
   So significance goes like this Mid-Low-High (213).
   I'm not sure if this has a purpose or if it was done in an attempt to obscure the encoding.
6. So they have 64^3 values (AAA...///) to encode a 101 possible values (0...100).
   Evidently, they don't use all of them so they are jumping a specific amount of values every time.
   Example
   

   0​	​	QAA
   1​	​	QoA
   2​	​	RQA
   3​	​	R4A
   4​	​	SgA
   5​	​	TIA
   6​	​	TwA
   7​	​	UYA
   8​	​	VAA
   9​	​	VoA
   10​	​	WQA

7. In the previous example you can see the significance order. The 3rd character didn't change, the 1st character changed almost every 2 values and the 2nd character changed every time.
8. Now, you can also see that the encoding from 0 to 1 jumps from A to o. Based on that, you can calculate that their jump is 40. So the encoded values would go A, o, Q, 4. To be more precise, AA, Ao, BQ,B4...
9. Every time the center character reaches the end of its range "/", the left character increments. When the left character reaches the end of its range, the rightmost character increments.
10. You can also note that they don't start at AAA. Some colors start at different encoded values but some use the exact same encoding scheme.

In the end I dumped all possible values, it took me like 2-3 hours. Instead of going with an elegant transfer function I ended up with the lazy approach of dumping those values in a lookup table.
Now I no longer need to use the *^^*&*%$%$ app that makes the fish freak out while I'm changing calibration.
I just define the values in a table and export the save file. I still need to open the app to import the file but I definitively prefer typing values in a table.
I'm very much looking forward to controlling the values via Bluetooth using my Apex and I hope we can continue collaborating.
The main reason why I thinker with the lighting is that I briefly change from blue to white lights to take pictures and I stop the flow at the same time.
In the meantime I control the vortechs and my return pump with Apex+WXM but the lights are independently synchronized.

 

[mard]

That's great work Mike!

Yesterday/last night I spent several hours going through the decompiled Mobius app in an attempt to find out how it calculates the checksum. Good news, I found it and was able to reproduce it (sort of). Hopefully I can wrap up the part of the investigating tonight and post my findings.

More good news, since I now have the Mobius (decompiled) code it should be easier to figure out what is needed for our use cases. Progress!

 

[MikeTheNewbie]

That's really cool mard!
What do you guys think about standardizing the hardware we use and setting up a github page to share code?
I initially used a fancy/expensive hardware to sniff BT but it doesn't have transmit capabilities.
I have nRF Connect in my phone from an old experiment but I didn't realize we could use it to replay messages.
I saw there is a version for windows that can be used with a $10 dongle (nRF52840). That might simplify things.
I would like to find out a cheap micro to use so I can compile trials and see things happening. I know that engages me and motivates me to spend more time on a project

 

[mard]

Great minds think alike. One of the reasons I got the Arduino Nano 33 BLE (~$21) was because I wanted to play with investigate with it and it seemed to have all the things I was looking for.

Once I have a little better understanding of what is going to be needed for the BLE communication, I'm planning on creating a GitHub repo for the Arduino library. But it certainly could also be the home for other Mobius integration efforts (if you would like to use something other than an Arduino).

 

[garbled]

Just FYI, ESP32's have BLE+WiFi builtin, and run like $5 on amazon. They are great chips, I use them for everything.

In theory too, if you have a std library for handling your device, it wouldn't be hard to integrate with something like ESPHome and be able to control it with homeassistant, which I could see some people liking... But your std arduino library should provide that possibility anyhow.

 

[mard]

Yes those ESP32 series look like very good options too. And from what I just briefly saw, and what you alluded to, it appears my planned attempt at an Arduino library could also be used with those devices.

But I'm getting ahead of myself a bit. haha First I need to understand what the Mobius app is doing so I can have a better plan to replicate the BLE messages for our needs/desires.

 

[mard]

From my investigation, it appears the following message structure is followed for all communication.
02 + opGroup + opCode + mMessageId + mReserved + data(length) + data + crc

02​

Yep, just a hard-coded 0x02 byte for the beginning of every message.

opGroup​

This byte represents if the message is a request (C2CI_Request) or a confirm (C2CI_Confirm) message. I was mistaken above when I said "The first 4 bytes match the request message". 0xDE does NOT equal 0xDF.
C2CI_Request = 0xDE (-34)
C2CI_Confirm = 0xDF (-33)

opCode​

This byte represents the operation code (or what I referred to as the message "type" above). There were about 14 different values which I found in the de-compiled code, but only two are relevant here.
"get" operation = 0x17 (23)
"set" operation = 0x18 (24)

mMessageId​

Pretty self-explanatory. It's a 2 byte message ID.

mReserved​

These two bytes are a little difficult to decipher because it can actually represent many things. They get updated in methods named "doNotRespond", "superuser", "setGroup", "setFsciInstance". But my guess for the messages which I've seen is that only the "setGroup" was being called. More examples would help confirm this.

data(length)​

These two bytes identify how many of the following bytes are the actual data.

data​

The data being transmitted.

crc​

A two byte checksum value. While it doesn't seem to be a "standard" 16 bit CRC algorithms (from what I have found), I was able to see the de-compiled class used to calculate the value. With one small modification, the class is:

package com.c2.comm.utilities;

public class Crc {
    private static short[] crc16_table = {0, 4129, 8258, 12387, 16516, 20645, 24774, 28903, -32504, -28375, -24246, -20117, -15988, -11859, -7730, -3601, 4657, 528, 12915, 8786, 21173, 17044, 29431, 25302, -27847, -31976, -19589, -23718, -11331, -15460, -3073, -7202, 9314, 13379, 1056, 5121, 25830, 29895, 17572, 21637, -23190, -19125, -31448, -27383, -6674, -2609, -14932, -10867, 13907, 9842, 5649, 1584, 30423, 26358, 22165, 18100, -18597, -22662, -26855, -30920, -2081, -6146, -10339, -14404, 18628, 22757, 26758, 30887, 2112, 6241, 10242, 14371, -13876, -9747, -5746, -1617, -30392, -26263, -22262, -18133, 23285, 19156, 31415, 27286, 6769, 2640, 14899, 10770, -9219, -13348, -1089, -5218, -25735, -29864, -17605, -21734, 27814, 31879, 19684, 23749, 11298, 15363, 3168, 7233, -4690, -625, -12820, -8755, -21206, -17141, -29336, -25271, 32407, 28342, 24277, 20212, 15891, 11826, 7761, 3696, -97, -4162, -8227, -12292, -16613, -20678, -24743, -28808, -28280, -32343, -20022, -24085, -12020, -16083, -3762, -7825, 4224, 161, 12482, 8419, 20484, 16421, 28742, 24679, -31815, -27752, -23557, -19494, -15555, -11492, -7297, -3234, 689, 4752, 8947, 13010, 16949, 21012, 25207, 29270, -18966, -23093, -27224, -31351, -2706, -6833, -10964, -15091, 13538, 9411, 5280, 1153, 29798, 25671, 21540, 17413, -22565, -18438, -30823, -26696, -6305, -2178, -14563, -10436, 9939, 14066, 1681, 5808, 26199, 30326, 17941, 22068, -9908, -13971, -1778, -5841, -26168, -30231, -18038, -22101, 22596, 18533, 30726, 26663, 6336, 2273, 14466, 10403, -13443, -9380, -5313, -1250, -29703, -25640, -21573, -17510, 19061, 23124, 27191, 31254, 2801, 6864, 10931, 14994, -722, -4849, -8852, -12979, -16982, -21109, -25112, -29239, 31782, 27655, 23652, 19525, 15522, 11395, 7392, 3265, -4321, -194, -12451, -8324, -20581, -16454, -28711, -24584, 28183, 32310, 20053, 24180, 11923, 16050, 3793, 7920};

    public static short crc16(byte[] bArr, short s) {
        for (byte b : bArr) {
            s = (short) ((s << 8) ^ crc16_table[(b ^ ((byte) (s >> 8))) & 0xFF/*UByte.MAX_VALUE*/]);
        }
        return s;
    }

    public static short crc16(byte[] bArr) {
        return crc16(bArr, (short)-1);
    }
}

This class is given the previous significant bytes (opGroup, opCode, mMessageId, mReserved, data(length), data) to calculate the 2 byte value which is then appended to the message.


Next up: trying to decipher the data portion.

 

[MikeTheNewbie]

Awesome! This thing is going great!
BTW, about hardware for BLE, a while ago I bought 2 of these ESP32 with a little OLED screen. I paid $10 shipped from china but I see they have them @ $13.25 in Amazon.
Handling the screen is really straight forward and helps debug code more easily. I programmed it in C++ and the Arduino IDE. I think there are phyton based ones.

ESP32 OLED Module ESP32 OLED WiFi + bluetooth Dual ESP-32 ESP-32S ESP8266

Only US$20.99, buy best ESP32 OLED Module ESP32 OLED WiFi + bluetooth Dual ESP-32 ESP-32S ESP8266 Geekcreit for Arduino - products that work with official Arduino boards sale online store at wholesale price.

www.banggood.com

You can also find it in amazon, just search for "MELIFE 0.96" OLED ESP-WROOM-32 for ESP32 Display 2.4GHz WiFi Bluetooth Dual Mode Development Board Display for Arduino Wemos AP STA" (I think R2R blocked the link.)
I think that would take care of our BLE comms but the analog inputs only support 0 to 3.3v ADC. We'll probably need the i2c ADC that @garbled suggested. What do you think?

 

[mard]

That looks nice. I think that will be going into my Amazon cart next.

From what I have seen (but I'm new to this sort of thing) is that there isn't really any ADC that can handle the max 10V. So to be safe we'll likely need to have a voltage divider regardless.
I've already adapted an old 3.5mm headphone extension cable for my use. The 3.5mm headphone cable actually gives me two separate channels/signals. I cut the cable in half and added/created an "inline" voltage divider on the female end for each channel to drop 10V down to ~3.3V. Then I connected that end to my Arduino board (which may end up being an ESP32 ). This way I can connect the other (male) end to me controller and can "plug-n-play" devices (as long as they have a 3.5mm female jack connector).

My vision for the library is to allow "users" to determine the actual "voltage" logic (along with other "business" requirements haha). Basically the library will hide/encapsulate 95% of the Mobius specific stuff and provide simple methods like connect() or runScene(x) or even crudely sendData(x) (obviously a rough guess for methods haha). So if their device or setup has a different voltage range they can program whatever they desire.

 

[garbled]

One quick note with the ESP32, use an ADS1115 for your ADC. It's way more accurate than the builtin on an ESP, and probably on a nano too. This is super important when you divide the voltage down, because an ESP32 ADC has trouble reading near-zero VDC, while the ADS1115 does great at it.

It's a super cheap part, and it's just an i2c connection. It can handle 4 inputs.

Other option might be an INA219. I largely suspect you could just wire the voltage straight into one of those.

Great work btw!