More info on how this was connected

[lemiesz]

Hi,

Forgive me I am not vert experience with IoT controllers. Could you possible give me some more detail on how you connected the wifi module to your desk, if you still have it could I see a picture?

Also, do you think it would be possible for me to prototype something like this with a direct ethernet connection from my laptop.

[malfroid]

I am also very much interested on how to practically connect a V3 Nodemcu-CH340 board (based on ESP8266 ES-12E) through 8P8C connector and UTP cable to the Fully Jarvis components (desk handset, desk controller box).

Do you strip the different wires in an UTP cable and solder to the ESP8266 pins?

How do you connect three UTP cables coming from desk handset, the desk controller box and the new components (ESP8266)? Do you use some kind of Ethernet hub for this?

[phord]

At first I used some stripped spare CAT-5 cable to make it easier to reverse-engineer the signal pins from the Jarvis controller. I brought these out onto an 8-pin connector on a breadboard and attached my logic analyzer to do signal captures. I use the USB Logic Analyzer from Sparkfun with sigrok/PulseView on Linux.

After that, I connected an ESP8266 to the same breadboard and started tinkering from there. It was rather ugly.

I started to design a proper circuit in some EDA tool, but I'm terrible at that. So I took the quick route one afternoon and drew some traces in an online Pebble tool. I'd post the netlist here, but it's not terribly useful unless you have the same board I do. Also, I'm not sure it's correct; I only used it as a guide. I ended up moving things further apart later and I left off the boot-mode switches.

Columns 1-8: RJ-45 connectors
Columns 10-15: FTDI serial programming interface
Columns 20-28: Digistump Oak ESP-8266 daughterboard

I didn't use a NodeMCU module for this, but I easily could. I used an ESP8266-based Digistump Oak board because I have a few handy from their kickstarter a few years ago. I don't recommend them, otherwise, since their plans got shanghaied by a poorly executed partnership with Particle.io.

I breadboarded it on my bench to get it working. Later I converted that to the Pebble breadboard layout above just so I could double-check things and play with other ideas.

The interface is really simple. I draw power from the Jarvis controller itself. There is almost always enough current to drive the ESP8266. I have had some occasional problems that might be caused by brownouts, but I'm still not sure.

The only clever part worth mentioning is that I mounted two RJ-45 jacks on the board in a pass-thru configuration. That is, there are two RJ-45's mounted together, one is rotated 180 degrees on two axes, so the pins all connect "straight through". This is easier to see on the next picture.

• Conn1.Pin1 goes to Conn2.Pin1
• Conn1.Pin2 goes to Conn2.Pin2
• ...
• Conn1.Pin8 goes to Conn2.Pin8

Look at the pair of connectors at H1-8 and I1-8 on the Pebble breadboard above. One of those is actually below the board pointing down instead of up. Each pair of pins on those two connectors is electrically connected (because of the breadboard). Then I mounted one RJ-45 to the top set of pins and the other one to the bottom set of pins. The bottom connector is rotated and turned around to face the opposite direction so the pins all connect as described.

I mounted all this on an Adafruit Permaproto Board. These are nice to have around for me. Then I plug the Jarvis Handset's RJ-45 cable into one of these (it doesn't matter which one), and I use a regular 8-pin network patch cable to connect the module to the Jarvis controller itself.

By the way, the handset is optional. You could drive it all from the ESP8266. The passthrough works well, though.

Note: If you get the RJ-45 breakout board from SparkFun, it makes it easy to stack these on headers. But be careful when assembling it because Pin-8 is mis-labeled as Pin1 and vice-versa. Read the user comments on the product page to see more details.

[glrs]

So it seems 3.3V is enough for a logical high when sending commands from ESP (3.3v) to the controller and handset (5v). Or is there something more to it?

Also, I see you do RJ-45 crossover passthrough. Do you rely on the ESP packages you send to being dropped by e.g. the controller when you address the handset, and vice-versa? Did you notice any interference?
My idea was to echo messages with ESP bidirectionally (H <---> ESP <---> C), which I must admit it'd be a pain... with only additional benefit the possibility to filter messages (and avoid potential interference, if there's any).

(BTW, I have the JCB36N2 controller and JCHT35M16C handset. I saw another discussion about a potentially different protocol. I hope that's not the case, but if so, I'll comment on my findings there.)

I cannot thank you enough for your work on this!

[phord]

All the lines are pulled high normally by the desk controller. To signal anything, my controller only needs to pull the line low. This is true for the HS "button" lines as well as the TTL-serial data lines. Fortunately, 3.3v and 5v signaling have compatible ground levels at 0.0v.

The lines are also all unidirectional, as far as I can tell. There are no serial commands I need to send to the desk controller, but I did experiment with them to show that I can. It makes total sense to split the serial line like an "intercept-relay" instead of a "sniffer-injector" if you want to modify or block commands going across this interface, but it's much more complicated to do. The sniffer is fine for my purposes, so I'm happy to use the simpler setup.

I originally used different Rx/Tx lines and software serial to avoid programming interference with the desk serial lines. But I normally unplug the desk RJ-45 when I want to program the ESP. Lately I've been using OTA programming on some other projects, and I'll probably use that on here, too.

[phord]

Here's another view of the board in the same orientation as the Pebble image.

1. I found I needed more space for the FTDI connector to fit because the FTDI-board is wider than the connector. So I moved the Oak pins over two more places and removed the switches.
2. I think I had the serial Tx/Rx pins reversed on the Oak, too. Even though you can't see it here, the green and blue wires that go to pins 24/25 are backwards.
3. If you look closely at the RJ-45 breakout, you might notice the square pin on the right. This usually indicates "Pin 1", but on this board it is a mistake; it's actually Pin 8.

[phord]

Also, do you think it would be possible for me to prototype something like this with a direct ethernet connection from my laptop.

@lemiesz The RJ-45 connector here is not used as an Ethernet connection. The electrical signals are all different. So no, you cannot connect this to your laptop's Ethernet port.

[brettmross]

Hi @phord,
First off, a huge thanks for this! I would be exaggerating my knowledge/ability if I described myself as a newb! I have been searching for a way to control my desk via Alexa, but haven't managed to find anything that will get me remotely close! My controller module is JCB35NS1 and Handset module JCHT35K22-1, so I understand that the protocols may be different as previously mentioned. Also, I am using a Nodemcu v3 ESP8266.

Am I right in thinking;

If I edit JarvisDesk.cpp and replace pins as follows;
P9 -> 6
P8 -> 1
P7 -> 8
P5 -> 0
P3 -> 9
P4 -> 10

Then if I patch the RJ45 passthrough between handset and controller to the ESP8266 as follows;

RJ45 -> ESP8266
8 -> 6
7 -> 1
6 -> 8
1 -> 0
4 -> 9
2 -> 10

I'm hoping that this will allow the monitoring to work without frying either the desk or the ESP8266! Once I have figured out the right commands\protocol, I just want to be able to ask Alexa to sit (Trigger memory position 1) and stand (Trigger memory position 2). I'm hoping to combine this with FauxmoESP to get it accessible with Alexa.

I'd appreciate any guidance or assistance you could offer.

Thanks

Brett

[soltmar]

Hi @brettmross and @phord ,

Did you manage to set this up for NodeMcu V3 ?

I'm looking to automate my Jarvis desk with JCB36N2CA control box, JCHT35M16-1 controller and NodeMcu V3.

Having some diagrams and software version for NodeMcu would be really helpful as I have no much experience with it.

Thanks

[phord]

Apologies to @brettmross , but I missed this post last year. Your thinking is correct. You should be able to replace the pins I used with direct GPIO numbers for the NodeMCU. I would caution against using GPIO 0, 1, 2, or 15 however, since these can interfere with the bootloader startup. That is, it's possible to use them, but they come with some restrictions. You should make sure the pins you hook them to don't cause problems. See ESP8266 Pinout Reference: Which GPIO pins should you use?

I think it's fine to use 9 and 10 for the UART pins, but you may want to swap them; that is, use GPIO9 (RX) for the desk's UART TX function on RJ-45 pin 2. This is because receiving the height data from the desk is probably more interesting than reading the handset commands being sent to it, and using the UART RX for the desk's TX pin will work more naturally. (But since I use SoftwareSerial in my code on both pins, maybe this doesn't really matter.)

On the other hand if you want to use the serial port for debug output with Serial.print(), you may want to use two other pins for DTX and HTX.

My recommendation would be to use pins D0, D1, D2, D3 for HS0-HS3, and then maybe use D5 and D6 for HTX and DTX. (Skip D4 / GPIO2 because if it's pulled low during boot, your code may not start correctly.)

[phord]

@soltmar Today I noticed I could easily drop-in a Wemos D1 Mini where my Digistump Oak sits with only a few modifications to my carrier board. Since the Oak is not manufactured anymore, I decided to update this project to use the D1-Mini. It worked perfectly fine and the only thing I changed in the code is the pin definitions. See e859bc323368.

I know that's not a NodeMCU, but the process is exactly the same. I think you can even use the same D pins I used on the D1 mini. Just connect your RJ-45 interface pins to those pins on the NodeMCU and the code should work as-is, now.

[nikandriko]

It seems to me on the Pebble image above a couple of the RJ-45 pins are wrongly wired on the image.
I'm reaching this conclusion when comparing the RJ-45 pins <--> Label table with the pinouts references in the code.

RJ-45 Pin	Label	Oak Wrong Pin on Pebble --> Correct Pin (based on JarvisDesk.cpp file)
1	HS3	P5 --> P2
6	HS2	P7 --> P10

[phord]

No, the pins in the original Pebble diagram for the Oak do match the original code. My Oak is mounted face-down so P5 is the third pin down from the top on the left, and P7 is the third pin up from the bottom on the right.

I never actually hooked up HS3 on my board since it's not generally useful. However, HS2 is correct in the photos, too. It goes to P7 on the Digistump Oak.