Initial setup questions and feedback

[netmindz]

Please use this discussion for any questions about what control units are supported, the current feature set, the hardware needed, Home Assistant integration etc

https://github.com/netmindz/balboa_GL_ML_spa_control/wiki/Install-Guide

[caldog20]

Question on the wiring setup.

I am using an ESP32. The RS485 TTL converter I purchased claims to support both 5v and 3.3v logic levels at the same time.

I did go ahead and buy bi-directional 3.3v/5v logic lever shifters. Are you using a logic level shifter for the rs485 serial connections and for Pin5 or stepping down Pin5 another way?

I have a buck converter that produces 5V I can use to power the esp32 through the USB port, with power incoming from the tub.

Also, from the install guide, I don't believe we do anything with pins 2 or 4 correct?

Thanks,

[netmindz]

At first I powered the RS485 adapter as 3.3v and used a level shifter for pin 5 (panel select). However, I think the level shifter was introducing a delay, as I had much better success when I risked applying 5v to the ESP32 and for both me and @tmjo we found we could not send any data to the RS845 unless it was powered by 5v.

While the output of the esp32 is only 3.3v it appears to be 5v tolerant to some extent (I have killed a few during this project). I'm more of a software developer than electronics engineer, so might be better way to get lag-free 3.3v using voltage divider resistor setup or similar, but personally at the moment I'm just banging 5v from pin 5 into the esp32 without issue

[caldog20]

One other issue I am wondering If I will have is that my original ML700 panel is toast. Therefore, I won't be able to sniff a UUID of the panel if that is needed. I imagine if we can calculate the right CRC value based on the UUID it won't matter? Not sure if the board actually verifies the UUID of the panel and compares.

[netmindz]

I'm pleased to report that @tmjo has been able to drive his control unit using the uid value from my top panel, so no need to change to your own. So long as we have FB commands with valid CRC we are all good, by removing his uid values and putting all the sixes as placeholder has just confused things a bit really

[StumpyRob]

Hi Guys,

All the kit has arrived so I'm ready to have a play this weekend! First off I want to thank you guys for al your work. I will try to spread the word as much as possible about this. - I'm surprised it hasn't got more exposure!

I have a few questions:

1. I have used Platformio to upload the code to my ESP32 (ESP32-WROOM-32D) I have a successful upload for the wemos_d1_mini32 but a failure for remote_wemos_d1_mini32 and d1_mini_lite. I'm presuming that's normal behaviour? - the code has been designed for multiple boards and the correct one has been uploaded for my ESP32?
   (First time I have used Platformio and I'm quite impressed by it!)
   

2. In the installation instructions, after upload of code it states "Then go to that address in the status page" - I can see the IP that the ESP has received form DHCP, I can ping it and I can telnet to it. Does the ESP host its own webpage? Am I expected to see something if I browse to it on port 80/81?

3. Finally, I can see in HA that the ESP32 is trying to connect to the MQTT mosquito broker. - awesome! However, I'm getting the error: "New connection from (IP ADDRESS) on port 1883. Error: received null username or password for unpw check"
   Is there a way to add credentials to the ESP32 for the broker? - I don't think mosquito allows anon. credentials. If not, can you advise what setup you are using?
   
   

I did also had a question about pin5 not being directly connected also however, @caldog20 has already asked about that. 👍

I would love help contribute to this. Once I get it going I would be happy to write a low level guide for users like myself!

[netmindz]

I've just pushed the newer code that supports read-write control of the tub to main btw

[netmindz]

Can you add a new diagram with the connections to the right pins please @StumpyRob and I will add to the docs

[StumpyRob]

Awesome! Thanks for the reply.

I will get a diagram over to you later on tonight.

The tub is in centigrade I will have a play probably tomorrow with the new code and let you know how I get on. I will also take a look at the serial output too. 🙂

[StumpyRob]

Here is the edited version. Glad I could contribute in some way - even if it is just a crappy diagram! 🙂

[netmindz]

Every bit helps. Guide updated

[caldog20]

Just a quick update. My supplies came in, and I was able to do some testing.

The transformer on my board fried so I had to order a replacement to fix it. But until that comes in, I was able to find another 120V to 12V AC transformer to connect up to the board to power the low voltage components just for testing. I was able to communicate with the board from my esp32 and also send commands. I was able to toggle the light and jets. I was also able to get the temperature.

As soon as my new transformer comes in, I will have the board back in the tub so I can see what it shows while actually running the tub.

[netmindz]

Given CTS/RTS is specifically listed as being used for half-duplex stuff like RS485, it is definitely an idea worth exploring. I've not really found much info on it as hardware flow control is such an old thing, so I can't confirm what we see on the scope. What surprises me is how it seems to toggle back and forth and a fixed clock rather than relating to if the controller is actually sending any data or not.

I did experiment a bit with the use of interrupts before I found that the level-shifter was adding a delay. If I remember correctly , then I could use that to trigger the read of the FA message, but if I tried to write then it broke stuff as you can't/shouldn't write serial data during the interrupt

[caldog20]

Are you thinking that a couple of the pins on the board may be used for flow control?

[caldog20]

Been doing some testing today. I have both the pump select and mode select switches working. I think we were just sending the commands too fast. For instance, when changing the mode select or the pump select, the first command is processed, but the rest are dropped. Typically, I think that the panel is sending empty replies between the button presses. If you think in terms of a human using the panel, there is a delay between pressing the buttons even if it's small.

Also, I have removed resending of commands and instantly dequeue them after they are sent. I haven't had any issues with needing to resend a command before getting a response, and none of the basic commands like up/down/light/mode button are dropped, so I think we are sending the command at the proper time. The delay in microseconds could probably stay incase others need to tune for different boards running at different frequencies, but I don't think the issue here is with that piece.

For now, I have placed some empty commands between the actual commands when doing mode/pump selection changes. This seems to provide enough time for the board to process the commands between entering menu's etc. I am going to keep testing and see if there is a more elegant way to solve this.

One thing I was thinking, we could define a command struct, similar to this:

struct Command {
  String command;
  int emptyCount; // basically a delay count
}

and use this in the HA callback functions, this way it's more clean, but can queue up empty commands more easily. Otherwise going off of a simple delay number might be difficult because of the place we are calling sendCommand() and the conditions around when it's triggered.

Anyways, I will keep trying to tune it. Let me know what you think.

[caldog20]

Also from my research, these boards don't use hardware flow control. Funnily enough, the board and top panels use the good old max485 IC for rs485 tranceivers. The flow control is usually done in software, or by some other means. This makes sense when you think about the pin5 for each panel. This is basically a flow control mechanism in itself, to allow the panel to know when to read or reply. Otherwise it will use the messages to determine flow control (when to send). I could be wrong but this is what I am leaning towards anyways.

[netmindz]

Interesting that you are getting better success rate than me. I see a few sends before my light will toggle. I have to admit though that my current physical setup is less than ideal as it's gone through a few iterations so I have wires stuffed into female headers where previous rs485 adapter boards were plugged in etc. It could do with a rebuild.

I could well be entirely wrong about pin 2 and 4. They must be for something, maybe I'm just desperate to know what 😅

Pin5 doesn't tell you when it's ok to transmit, but yes the protocol allow for a time period after the FA is sent by the controller for the top panel to send an FB so a delay is ok, but as an esp32 is more complicated than what they are using, we have various async stuff that the original boards don't which might make timing a little harder for us.

With regards to the command strut, this would only be needed if we need a different number of idle commands for different actions.

Would be really interesting if someone could open up one of the panels and trace on the pcb where if anywhere pin 2 and pin 4 go

[caldog20]

I will take a look! I want to go out though and switch my dipswitch to C temp and make sure the byte value being read in #10 is still F on my system, just incase there is a difference. I haven't done much with HA but I was thinking that if we check the byte for C/F in a status message we could then dynamically update `targetTemp.setUnitOfMeasurement("°F")` and `temp.setUnitOfMeasurement("°F")` so users wouldn't have to make changes if their tub is using either, if that's okay with everyone. But if we can't dynamically update the unit of measurement we could just have 2 temp values for current/target similar to #10. Yeah, both of my pumps are dual speed. The speed setting for both pumps is currently working from HA for the most part. However, I think we may need to adjust it a little. For instance, if you are in High speed, and try to go to medium, _sometimes_ it turns it off. This is similar to the bug with the Mode setting. I went over the formula for the mode setting and it seems we are sending the right number of button presses, but I think it's possibly sending them too fast or too slow to be picked up. I planned on doing more testing on that and try to adjust. That would fix both the mode selection and make the pump speed selection more reliable.

…

On Jun 29, 2023, at 12:29 PM, netmindz ***@***.***> wrote: Possibly just use this? #10 <#10> Just to be clear - you have dual speed pumps and control from HA is working for both and at the correct speed? — Reply to this email directly, view it on GitHub <#24 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACR3MGDDP6SWRSI2D5VWIZ3XNW3OTANCNFSM6AAAAAAZJE5LNI>. You are receiving this because you were mentioned.

[netmindz]

My earlier code to try changing between standard and eco added space between the commands by sending idle commands. Might be worth a try adding an idle after each jet button press

[tmjo]

Yes, that is my thinking too. We see the original panels seems to send "empty" commands basically all the time. Perhaps there is some kind of reason for that. I was supposed to test during the weekend, but got caught up in other stuff that I had to take care of, so better luck this week perhaps.

[netmindz]

Yeah, I'm unsure what the point of that is, given the pin5 panel select time is fixes, so it's not like you are preventing blocking waiting for timeout for response from a panel where none might even be connected

[tmjo]

I'm seeing similar results as @caldog20, i.e. removing the resending of commands and adding some "padding" with the emty commands (typically 4) to have my commands act the way they should. Then pump, light and temp control is ok. I got some issues with the mode change (which used to work), but probably just some minor stuff I didn't see.

I will test with sending single commands on each PIN5 low. Depending on the speed of our ESPs it could be we're sending several commands on every PIN5 low, and perhaps that is not the intention? Perhaps it should be a single command.

[netmindz]

Can't send multiple commands per pin5 btw as we only trigger after we read the FA message and that can be only once per pin5 cycle @tmjo

[tmjo]

You're probably right. Even if there were several loops per pin low, the buffer would be empty and not enter the if-statement I guess. It was just an idea I had, but probably not anything worth following up on then.

I we conclude that the concept of 3-4 empty "paddings" works consistently, I guess that is jolly good, it just seems a bit weird. On the other hand, our panels send empty commands all the time and human interaction would certainly have a delay, so perhaps that's just the way it works.

[netmindz]

Does this do the same as you were trying? I've not tested yet, but hopefully matches what you are seeing @caldog20
@tmjo #36

[tmjo]

I'll see if I can test tomorrow. Was going to send a PR by the way, but other stuff came in the way.

[netmindz]

I tested and it fails, but think that might be my own hardware setup