Help with kessil ap700

[collibric]

Ok folks, i'll shade some lights on this, but before that, let me clarify I have not read the whole thread. And the advice shared here are my learning from setting up reef-pi as access point / remote access etc.
...

I have some notes on this amazing lights and how it is communicating..

I have three of AP700's prepared for my future tiny nano reef upgrade, from summer 2017. But until now I didn't hook them up (still too small tank, A360WE was good enough on simple On/Off timer, until now) ..

But what I did once I've got them - I've been sniffing the app communication between the app and units, just because units has been behaving inconsistently when I've been setting them up for initial test after purchase.

Two of the units have serials just above 1000, one of the is older, above 200 .. LED arrays configuration slightly differs on that batches.

(notes below are just as I remember it from summer 2017 messing)

- Each of the units is probably carefully calibrated to have some defined spectrum output - each of the device has been reporting back to the application unique values causing different values sent from application to each device to set each channel levels, the older one way more, the new ones values were near themselves.
- I've been successfull to control the lights just using sniffed data and control basic light functions (on/off, light color, intensity ...) just by rebuilding correct TCP packet using basic perl library.
- I've been unable to recognize what all is in the packets, but there was no problem to sniff steps 0-100% for each color and mix them and use them as I like to.. (keepin' in mind, that running all channels on 100% is not a good idea, if original app is not doing so.. so I stayed just on sniffed levels and below)
- I was unable to control each led array independently, nice to have for dusk/dawn or to tune light amount on the tank sides .. but storm demo shows that internally they are independent - maybe later.
- One of the unit stopped to respond on wifi after messing with setup of wifi module .. it ended up with uncovering the wifi module inside an ap700 and after googling the module label on the internet and reading the datasheet, I've been able to reset it to factory defaults just by shorting out two pins on it (btw. nicely waterproofed by kessil, the same like on my A360WE) .. worked again .. huh

my main focuses was:
- to be sure, that lights will follow my own externaly controlled program - I see no problem with that
- get the moonlight under my control to keep it low enough, and to sync it up to real moon dusk/dawn/level above me - definitelly possible
- control the LED arrays on light independently - seems not easily possible
- connect lights to my home network and have them under control from wherever I am (i.e. when I see thru camera that acclimation is not gentle enoung) - no problem at all

So as finally I've hooked up the AP700 above my still tiny reef yesterday to let my corals have gentle dawn/dusk, and it is still not working as I wan't to, I'll be probably continue with the research to controll this lights from my NAS or RPI.

Question is - why there is still no i.e. apex control for this light ? It seems to be "trivial" to at least mimic the light control of the original application in manual mode (may be in programming mode also) from 3th party app .. ? ..

to go back to the topic - packet setting time (or packet which recovers light to program point where it should be) can be easily sent from anything on your network where you are able to add a little TCP packet creating script.. seems to me that I'll need it too, as my light did not wake up correctly today. Tomorrow I'll shoud recieve RPI and HAT automation module for play ..

 

[collibric]

I've found my old records of reverse engineering of the communication .. (as I have more lights, 174 is indicating light ip ending by 174, others are 106 and 107, ALL means the same data sent to all)
Init Comm
a9:04:01:00:09:f2:5c ->174 ?whatsyourname?
a9:0e:01:00:09:4b:44:31:36:30:35:30:30:37:32:c4:5c 174-> my name is KD16050072 [4b:44:31:36:30:35:30:30:37:32]
a9:04:01:00:08:f3:5c ->174 ?fwr ver?
a9:08:01:00:08:56:33:34:30:02:5c 174-> fwr ver is V340 [56:33:34:30]

color set manual mode
a9:22:01:00:01:46:05:53:03:46:05:01:00:fd:00:00:00:6f:05:47:03:6f:05:01:00:fd:00:00:00:00:00:00:00:00:26:9c:5c - White 15 ALL
a9:22:01:00:01:7c:06:60:03:7c:06:01:00:d9:01:00:00:c0:06:54:03:c0:06:01:00:d9:01:00:00:00:00:00:00:00:47:95:5c - White 28 ALL

a9:22:01:00:01:01:00:01:00:01:00:01:00:01:00:3e:05:01:00:01:00:01:00:01:00:01:00:01:00:00:00:00:00:00:47:47:5c - Green 28 ALL
a9:22:01:00:01:01:00:01:00:01:00:01:00:01:00:c4:08:01:00:01:00:01:00:01:00:01:00:01:00:00:00:00:00:00:a8:5d:5c - Green 66 ALL

a9:22:01:00:01:00:00:00:00:00:00:00:00:1f:02:00:00:00:00:00:00:00:00:00:00:2d:02:00:00:00:00:00:00:00:00:8c:5c - BlueMoOn 106
a9:22:01:00:01:00:00:00:00:00:00:00:00:f2:02:00:00:00:00:00:00:00:00:00:00:bc:02:00:00:00:00:00:00:00:00:2a:5c - BlueMoOn 107
a9:22:01:00:01:00:00:00:00:00:00:00:00:26:02:00:00:00:00:00:00:00:00:00:00:26:02:00:00:00:00:00:00:00:00:8c:5c - BlueMoOn 174
a9:22:01:00:01:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:02:02:00:00:00:00:00:ff:d9:5c - RedMoOn 106
a9:22:01:00:01:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:ec:01:00:00:00:00:00:ff:f0:5c - RedMoOn 107
a9:22:01:00:01:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:1c:02:00:00:00:00:00:ff:bf:5c - RedMoOn 174

a9:05:01:00:27:01:d2:5c - OnALL 3 times repeated
a9:05:01:00:27:00:d3:5c - OffAll 3 times repeated

interesting request -> response:
a9:05:01:00:03:21:d6:5c
a9:1d:01:00:03:21:00:00:00:00:00:00:00:00:26:02:00:00:00:00:00:00:00:00:00:00:26:02:00:00:6e:5c - Blue Moon Calibration response to app?

and here we are back to topic:
a9:13:01:00:6e:00:32:30:31:37:30:37:32:35:30:32:30:37:31:35:b7:5c ->174 !?store datetime?! 20170725020715 [32:30:31:37:30:37:32:35:30:32:30:37:31:35]

here is sample script for data sending out of linux based NAS or Raspberry, or PC ..:
#!/usr/bin/perl
use IO::Socket::INET;
# auto-flush on socket
$| = 1;
# create a connecting socket
my $socket = new IO::Socket::INET (
PeerHost => '192.168.2.106',
PeerPort => '8899',
Proto => 'tcp',
);
die "cannot connect to the server $!\n" unless $socket;
print "connected to the server\n";
# data to send to a server
my $req = "\xa9\x04\x01\x00\x09\xf2\x5c"; #say your name
#my $req = "\xa9\x04\x01\x00\x08\xf3\x5c"; #fw version
#my $req = "\xa9\x05\x01\x00\x27\x01\xd2\x5c"; #turn on
my $size = $socket->send($req);
print "sent data of length $size\n";
# notify server that request has been sent
# receive a response of up to 1024 characters from server
my $response = "";
$socket->recv($response, 1024);
$answer = <$socket>;
print "received response: ".hex $response."\n";
print "received response: ".hex $answer."\n";
shutdown($socket, 1);

$socket->close();

more magic to come .. maybe ..
(just be careful to not fry your lights - do not send fffffffffffffffffffff to all color channels ..)

 

[collibric]

... soo ..." good news everyone" ..

I've been find out that at least moonlight can:
1) go lower in intensity .. a lot lower ..
2) CAN BE CONTROLLED INDEPENDENTLY ON EACH LED ARRAY

after I found out where and how there is calculated checksum in packets, I've started to play and I was happy that I was able to change intensity on left and right led array independently on moonlight mode .. tested moon dawn/dusk from left to right ..

after inspecting old data I've found out, that data different for each light unit has been related only to low levels of moon, other data seems to be the same for all of the lights, so unique calibration is hopefully needed only for moon light ..

here is updated script, uncommented is my new calibrated lowest moonlight (it is too low - each array needs to be tested how low it can go, non linear working area)..

#!/usr/bin/perl
use IO::Socket::INET;

# auto-flush on socket
$| = 1;

# create a connecting socket
my $socket = new IO::Socket::INET (
#PeerHost => '10.10.100.254',
PeerHost => '10.0.0.139',
PeerPort => '8899',
Proto => 'tcp',
);
die "cannot connect to the server $!\n" unless $socket;
print "connected to the server\n";

# data to send to a server
#my $payload = "04:01:00:09";#say your name
#my $payload = "04:01:00:08"; #fwr version
#my $payload = "05:01:00:03:21";#get blue moonlight level
#my $payload = "05:01:00:03:1e";#get red moonlight level
#my $payload = "05:0:x00:27:01"; #turn on
#my $payload = "05:01:00:27:00"; #turn off
#my $payload = "22:01:00:01:00:00:00:00:00:00:00:00:1f:02:00:00:00:00:00:00:00:00:00:00:2d:02:00:00:00:00:00:00:00:00";#set blue moonglight
my $payload = "22:01:00:01:00:00:00:00:00:00:00:00:0a:02:00:00:00:00:00:00:00:00:00:00:17:02:00:00:00:00:00:00:00:00";#set blue moonglight
$payload =~ s/://g;
my $payloadtmp=$payload;
my $checksum=0;
while ($payloadtmp){
my $tmp=chop($payloadtmp);
$tmp=chop($payloadtmp).$tmp;
$checksum-=hex $tmp;
}

$checksum=sprintf("%X", $checksum);my $tmp=chop($checksum);$tmp=chop($checksum).$tmp;$checksum=$tmp;
#print "$checksum\n";
$request="A9".$payload.$checksum."5C";#$request= $request << 2;#$request=$request|"\x01";
print "req = $request\n";
#print unpack('H*',$request)."\n";
my $size = $socket->send(pack('H*',$request));print "sent data of length $size\n";
my $response = "";$socket->recv($response, 2048);
print "received response:".unpack('H*',$response)."\n";
shutdown($socket,1);
$socket->close();
exit 0;

Raspberry is up and running, waiting for few more scripts to control at least my reef lights ..

 

[SparkyNZL]

Hi ,

I was wondering is someone on here would mind grabbing me the screen shots of the wifi controller, I reset it to factory and of course its not communicating with the gpio any longer.

If you connect to your lamps wifi (Kessil_KDXXXXXX)
go to http://10.10.100.254
login in is admin/admin (great security Kessil)
and grab me the screen shots of the first four menus would be great

Huge thanks
Sparky

 

[collibric]

I'll make screenshots of the wifi module settings for you, but can't make it tonight ..

 

[JamesP]

@collibric

I too have been thinking for a while about reverse engineering the AP700 API, and I just stumbled across this thread and the most useful data that you have posted in the last few posts. Unfortunately, I am away from the fixture for some number of weeks still due to work related travel, but please keep posting anything that you uncover.

What I was going to try and do was use a pi in conjunction with an Apex as a piece of middleware to convert either 0-10v or IoTA commands into something to be sent to the AP700 fixture to control it. Using 2 channels of 0-10v we can control basic white-blue spectrum as well as intensity similar to the A360WE, or perhaps using IoTA we can control all colors of the light independently such as for the AI fixtures with their IoTA capability. Maybe using 2 more channels of 0-10v we can control red and green as well since the Apex has a total of 4x 0-10v outputs. The pi would need to be smart enough so as not to overdrive the unit if receiving 10v on all 4 lines obviously.

Another thought that just crossed my mind is what if instead of trying to reverse engineer the web API, we can remove the serial lines from the Wifi-UART to the light and attach a 3.5mm jack on the housing of the light that is soldered to the main light board. I have not taken mine apart yet so I have not seen the internals to know how easy this would be, but if this were possible then we could send serial commands to the light instead of IP based, bypassing the IP portion all together. The lights could then be chained together using a 3.5mm cable similar to the A360WE, except instead of the cable carrying an analog 0-10v signal, it can contain the digital Tx/Rx/G RS232 signals between the lights that would bypass the network card all together. Serial protocols are usually easy to reverse engineer and we could get around the buggy IP module and control the LEDs directly. We could sniff the existing UART output with a PC containing an RS232 input as a start.

Out of curiosity, do you have any pictures of the internals of the unit? You said you took your apart and got to the WiFi module to reset it so I figured I'd ask.

 

[coastal_kid]

Can you tell me more about Option B? Wouldn't it require a way to fool the app into thinking it was connected to the right access point? And wouldn't it also require a proxy running on the Android device to route the request to the home? (Assuming the kessil uses IP routing. It is possible it just shoots data to a MAC address.)

 

[coastal_kid]

I'd like to try looking at the AP 700 protocol. How did you sniff the traffic between the app and the AP 700s?