Closed chunkysteveo closed 8 months ago
@tmh88 & @chunkysteveo could you post images of your PCBs? In essence I'd like to know if you have low pass filter setup implemented
I'm on pcbv1, just the level shifter, no filters
hi everyone i have the same issue i tried to update to the new v4 with my miami (2016) 4 wire model no 54123 and its not working with the old firmware it was all good im using the pcbv1
my display is just showing 00 and the buttons are doing nothing
the good thing is i have two nodemcu's so i can switch beetween the old and new version in seconds
perhaps i can do some debugging here
what i'm missing is also the CIO and DSP connected info in v4
here is an Image of my Board
hi everyone i have the same issue i tried to update to the new v4 with my miami (2016) 4 wire model no 54123 and its not working with the old firmware it was all good im using the pcbv1
my display is just showing 00 and the buttons are doing nothing
the good thing is i have two nodemcu's so i can switch beetween the old and new version in seconds
perhaps i can do some debugging here
what i'm missing is also the CIO and DSP connected info in v4
here is an Image of my Board
Same PCB setup and issues as me with the new firmware. - neat box!
The CIO_TX only showed that at least one proper message is received. It is replaced with a counter that increases every time a proper message is received. It can be found under TIMES info in the websocket messages. Start the browser inspect/console tab to see it. The DSP_TX is unfortunately not replaced with anything, but IIRC your problem is that you don't receive anything from the CIO.
Actually, I have added packet counts for both dsp and cio now. Will be included in next beta update.
Would it be possible to add a note to the README and Build Instructions to say that the current firmwire is known to be problematic with 4 wire setups? lt took a lot of troubleshooting and research before I located this thread.
Hi @MyMakibox I guess I could. Can you try the latest dev branch version and post two pictures for me: one on your hardware page with the pinouts and one of the results from layzspa.local/inputs/ This page is only available in the latest version. Test with device in pump. Thx
I came up with an idea today, of what may be the issue. The earlier versions was listening for serial messages and if either the DSP or the CIO was sending something, the ESP transmitted to the other end. In v4 both DSP and CIO has to send messages to get a response from the ESP. So what if, say the CIO, just waits for incoming messages before sending anything. In that case both the ESP and the CIO will just sit there waiting for each other. So I uploaded a new version where the ESP sends an empty message to both ends, hoping they start to talk. If this works - great. If it doesn't, I have another thing to try but it's more work so I have my fingers crossed. Can someone please try the developments branch now?
@visualapproach I have uploaded the latest fw from: https://github.com/visualapproach/WiFi-remote-for-Bestway-Lay-Z-SPA/archive/refs/heads/development_v4.zip
Firmware: 2023-10-26-2124 Model: NO54123
Before plugging in the ESP to the pump, I ran hwtest:
Start test. Seq begins with HIGH, then alters.
Sending on D1, receiving on D4 ---------------------------------------------------------------------------------------------------- // 0 errors out of 100 Sending on D5, receiving on D3 ---------------------------------------------------------------------------------------------------- // 0 errors out of 100 Sending on D0, receiving on D0 1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1- // 50 errors out of 100 Sending on D4, receiving on D1 ---------------------------------------------------------------------------------------------------- // 0 errors out of 100 Sending on D3, receiving on D5 ---------------------------------------------------------------------------------------------------- // 0 errors out of 100 Sending on D0, receiving on D0 1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1- // 50 errors out of 100 End of test! Errors indicated by 1 or 0 depending on test state. - is good. Switching cio pins 5s HIGH -> 5s LOW -> input then DSP pins 5s HIGH -> 5s LOW -> input, repeating Disconnect cables then reset chip when done!
As it seems no errors there?
I have been troubleshooting this issue now 3 days and as final resort soldered tx/tr cables directly to the ESP (just to see if there is faulty parts on the board).
As per first tests, the pump still stays offline. Display shows "00" and buttons on DSP do trigger (you hear beep), but they do nothing.
Is there any other debugging that could be done? It seems /inputs throws 404 error, yet I did build and upload data files from the dev branch as well.
Pump model is 54123 (2016 model / egg shape).
Let me know if there is anything else I could provide to troubleshoot this issue, or if you wish to get direct access to the ESP via cloud tunnel ;)
Edit: tried also enabling /debug-on yet 404 error was returned. Is there additional files I should upload to the ESP in order to enable /debug-on/off and /inputs?
Edit2: Figured out the debug and inputs issue, I was missing a / from the end of URL.
Inputs: Edges received on pin D1: 1 Edges received on pin D5: 1 Edges received on pin D0: 1 Edges received on pin D4: 239 Edges received on pin D3: 1 Edges received on pin D0: 1 Edges received on pin D0: 1 On 6-w pump the highest number is CLK, next is DATA and third is CS. On 4-wires the highest is CIO or DSP TX to ESP.
Nice , the hwtest passed. It seems I need to try the other trick since the cio is silent. Call you back.
Ohhh, new paths to test?!
My 'tub is currently empty, so could get the egg inside and run some tests on the dev firmware to help with the 4w issues.
Do you need more testing, or have you got enough info to "try the other trick" @visualapproach ?
Thanks @chunkysteveo I might as well use my trick before you test. I hope to have it up on github today or tomorrow. I'll post again here
Cool - looks like I may have a weekend task ahead, haha!
uploaded attempt 2 (dev branch)
uploaded attempt 2 (dev branch)
Uploaded and tested, no change. CIO side seems dead quiet. DSP does send data as it shows up on /inputs/. When buttons are pressed, you can see the value increase on D4.
Is there a way to listen and capture data sent by the DSP to CIO? As it could be that this particular model could send some sort of "wake up/ok" signal to the CIO and after that CIO activates?
Debug log.txt: "1698409556:0,0,0,0,0,0,0,0,0,0,0 ,0,0,0,0,0,0,0,0,0,0,0"
Inputs when buttons pressed on DSP (reverted back to default pins, still directly connected on ESP): Edges received on pin D5: 1 Edges received on pin D2: 1 Edges received on pin D0: 1 Edges received on pin D3: 1 Edges received on pin D4: 457 Edges received on pin D0: 1 Edges received on pin D0: 1 On 6-w pump the highest number is CLK, next is DATA and third is CS. On 4-wires the highest is CIO or DSP TX to ESP.
Inputs when DSP "idle" no buttons pressed: Edges received on pin D5: 1 Edges received on pin D2: 1 Edges received on pin D0: 1 Edges received on pin D3: 1 Edges received on pin D4: 235 Edges received on pin D0: 1 Edges received on pin D0: 1 On 6-w pump the highest number is CLK, next is DATA and third is CS. On 4-wires the highest is CIO or DSP TX to ESP
The pump works fine when DSP without ESP is connected, so "faulty pump" isn't the issue.
I read above that versions v3.4.0 and v3.4.1 works for some people, but I had no luck (probably because of the pin layout for pcb v2). Yet, that should give us some indication how the CIO on this model should be handled.
I would also like to clarify few things, is it enough to just restart ESP after flashing new FW/making changes to HW config? Or should the whole pump be power cycled?
Are there any additional debugging tools available if we compile the fw with the following flags (on pio.ini): ; build_type = debug ; debug_build_flags = -Og -g2 -ggdb2
From the /lib/BWC_unified/bwc.cpp I noticed the following:
if(!_loadHardware(ciomodel, dspmodel, pins)){
pins[0] = D1;
pins[1] = D2;
pins[2] = D3;
pins[3] = D4;
pins[4] = D5;
pins[5] = D6;
pins[6] = D7;
pins[7] = D8;
}
Am I reading this right that ESP D0-D8 pins (which I have now soldered DSP&CIO rx/tx cables) are referenced differently on the fw? Basically ESP D2 = D3 on the fw?
If I have soldered tx/rx cables directly to ESP pins: D2, D3, D4 and D5 on the HW Config I should refer them as D3, D4, D5 and D6 (+1 to ESP pin number)?
Don't want to hijack this thread, yet I have the exactly same issue and model discussed here.
@lazmo88 pins[] is just an array storing the config.
If I have soldered tx/rx cables directly to ESP pins: D2, D3, D4 and D5 on the HW Config I should refer them as D3, D4, D5 and D6 (+1 to ESP pin number)?
No you should refer to them as D2, D3, D4, D5. Connected to CIO RX, CIO TX, DSP TX, DSP RX (note the order rx-tx-tx-rx)
I think your problem can be caused by something else (like no LLC) and therefore I'd like someone else (@chunkysteveo cough...) to try it out, since he's got it working in the old versions. That way we can know better what your issue is.
The built in debugging tools will not help in this case. Actually they just crashed the program when I tried. What you can do is looking at the websockets messages by right clicking the browser window and select inspect. Choose console tab.
@visualapproach I can try and do some testing at the weekend, if this helps?
You're more than welcome! Remember you need the new hwconfig page also with the reversed order on DSP TX/RX
@lazmo88 pins[] is just an array storing the config.
If I have soldered tx/rx cables directly to ESP pins: D2, D3, D4 and D5 on the HW Config I should refer them as D3, D4, D5 and D6 (+1 to ESP pin number)?
No you should refer to them as D2, D3, D4, D5. Connected to CIO RX, CIO TX, DSP TX, DSP RX (note the order rx-tx-tx-rx)
I think your problem can be caused by something else (like no LLC) and therefore I'd like someone else (@chunkysteveo cough...) to try it out, since he's got it working in the old versions. That way we can know better what your issue is.
The built in debugging tools will not help in this case. Actually they just crashed the program when I tried. What you can do is looking at the websockets messages by right clicking the browser window and select inspect. Choose console tab.
Thanks for the reply! I have LLC in place and also capacitors and resistors. I just started to test the board backwards to the ESP to see if there are any issues with the components. I will re-solder everything today and try it out again.
Re:order of RX/TX/TX/RX isn't this configurable from the HWConfig? Or should I recheck cable order going to CIO again?
Okay I understand. I'd still want someone with a device known to work testing the update. The pinout is configurable from the HWConfig page, BUT if you come from an earlier version there is a change. First config had the fields RX-TX-RX-TX and now it is RX - TX - TX - RX. If using old page with new firmware it will not work. Also if using new page without resaving HWConfig, it will not work. Change was made not only to confuse the world, but also to make the HWtest working for 4-wire setups.
Okay I understand. I'd still want someone with a device known to work testing the update. The pinout is configurable from the HWConfig page, BUT if you come from an earlier version there is a change. First config had the fields RX-TX-RX-TX and now it is RX - TX - TX - RX. If using old page with new firmware it will not work. Also if using new page without resaving HWConfig, it will not work. Change was made not only to confuse the world, but also to make the HWtest working for 4-wire setups.
Ok, thanks for the details. I have uploaded both fw and data files from the dev branch, so that should not be an issue. ESP has been restarted between hwconfig changes also. One remaining question is, does the whole pump require power cycle when changes are made or is ESP restart sufficient?
I don't know tbh. I thought them 4-wire pumps threw E13 at you as soon as they smelled anything suspicious. Maybe your model just give up and remains silent. So to be sure, restart the whole shabang and check the overheat protection button on the side. Just press it. Probably overdoing things but it's happened before that it pops when you're messing about.
Added the LLC back to the loop and using the default pins CIO (D2/D5) DSP (D3/D4). HW test is no longer passing, is it a bad LLC or mixed up tx/rx?
Start test. Seq begins with HIGH, then alters.
Sending on D2, receiving on D4 ---------------------------------------------------------------------------------------------------- // 0 errors out of 100 Sending on D5, receiving on D3 -------------------------0-----------------0---0---------0-0---0---------------0-------0-0-------0-- // 10 errors out of 100 Sending on D0, receiving on D0 1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1- // 50 errors out of 100 Sending on D4, receiving on D2 -010---------------------010---0--1--01-1-----1---1----------------0----10----1--------------------- // 17 errors out of 100 Sending on D3, receiving on D5 ---------010--101-1-1---101-10101--0-01010-010-0-0--10--10-010101010--10----10-0---0-0-010--1---10-- // 53 errors out of 100 Sending on D0, receiving on D0 1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1- // 50 errors out of 100 End of test! Errors indicated by 1 or 0 depending on test state. - is good. Switching cio pins 5s HIGH -> 5s LOW -> input then DSP pins 5s HIGH -> 5s LOW -> input, repeating Disconnect cables then reset chip when done!
Start test. Seq begins with HIGH, then alters.
Sending on D2, receiving on D4 ---------------------------------------------------------------------------------------------------- // 0 errors out of 100 Sending on D5, receiving on D3 ---0-----0-----0---------------------------0-----------------------------0-------------------0-0---- // 7 errors out of 100 Sending on D0, receiving on D0 1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1- // 50 errors out of 100 Sending on D4, receiving on D2 -------0---------------
D3 to D5 is not super but will not be used in that direction. So give it a go
D3 to D5 is not super but will not be used in that direction. So give it a go
Did give it another shot, no go. DSP stuck on 00 and no commands taken from DSP or ESP.
Ran the hwtest few times, it seems to give different results.
Sending on D2, receiving on D4 ---------------------------------------------------------------------------------------------------- // 0 errors out of 100 Sending on D5, receiving on D3 ---------------------------------------------------------------------------------------------------- // 0 errors out of 100 Sending on D4, receiving on D2 ---------------------------------------------------------------------------------------------------- // 0 errors out of 100 Sending on D3, receiving on D5 ---0---------0-----------0-------------0-------------------------------0-0-----------------------0-- // 7 errors out of 100
Yet, sometimes there are errors randomly on the D2 > D4 as well. Is there level of "acceptable" amount of errors or should we expect 0 errors all times? If 0 errors is the goal, is there a component that can cause these errors? Flaky LLC or ESP itself?
I am parking this troubleshooting attempt for now and will keep monitoring updates here, if we get reports other people getting it to work with the dev branch, I have to look into to the HW and perhaps make a build from scratch.
So 0% errors is of course the ideal case but I think we can live with some errors depending on how often they occur. There is a checksum in the messages that will end up wrong if one or more bits are wrong in the first five out of seven bytes IIRC. So we need some whole messages to go through because garbled messages will be thrown away. This test is testing in a loop back that is not the same as in the pump. Every component will affect the signal one way or the other and at different frequencies so it's more a sanity check. It's the beauty of DIY ;) Did you try without the filters (using the a-hol.. I mean ports)? Cheers
So 0% errors is of course the ideal case but I think we can live with some errors depending on how often they occur. There is a checksum in the messages that will end up wrong if one or more bits are wrong in the first five out of seven bytes IIRC. So we need some whole messages to go through because garbled messages will be thrown away. This test is testing in a loop back that is not the same as in the pump. Every component will affect the signal one way or the other and at different frequencies so it's more a sanity check. It's the beauty of DIY ;) Did you try without the filters (using the a-hol.. I mean ports)? Cheers
Yep, tested also H1A and H2A ports without capacitors and resistors. No go.
Using latest development_v4 branch
Can you try the latest dev branch version and post two pictures for me: one on your hardware page with the pinouts
and one of the results from layzspa.local/inputs/ This page is only available in the latest version.
Thx, either not on latest fw or you didn't enter the URL right. Did you end with a slash?
Thx, either not on latest fw or you didn't enter the URL right. Did you end with a slash?
Yes, entered with a slash. I've tried deleting the repo, rebuilding, reflashing etc and still get that response. I can't rule out user error as I'm unfamiliar with platformio.
Is there any way to verify the version installed from the UI? The 'Check firmware update' page no longer supplies any information.
It's on the bottom of the main page. As a date
Ah thanks.. Firmware: 2023-08-19-2340.. not 2023-10-27-1400
Check the development branch for the latest version
Thanks, I had done that.
Maybe my problem is hardware? I tried flashing a bunch of times and while the upload seemed successful, the version number didn't change. Then I used the PlatformIO 'Erase Flash', and uploaded again.. but since doing that I haven't been able to detect the ESP8266 on wifi or via a "Lay-Z-Spa Module" access point. Sorry if this is off topic.
Cool - looks like I may have a weekend task ahead, haha!
Did you test it out? :)
it
I'm sorry, I've not had time yet to test. Sorry!!
I know I'm on Palm Springs Hydrojet (not air) 54144 with the "Square" pump unit rather than "egg", and on the v1 pcb, but its still 4 wire based
I've got control from the web interface working from master / tag v4.2.3, but when I update from development_v4 I'm not able to control from the web interface, and get the trusty old E13 error.
Looking in the console log, I think it looks to be sending the messages ok
dev_v4:
{"CONTENT":"TIMES","TIME":1699289793,"CLTIME":1695634495,"FTIME":1695634496,"UPTIME":4626094,"PUMPTIME":1149043,"HEATINGTIME":820155,"AIRTIME":0,"JETTIME":5007,"COST":1.271482348,"FINT":14,"CLINT":14,"KWH":15.89352989,"KWHD":448.4395336,"WATT":2,"T2R":9.801789284,"RS":"Not ready","DBG":" 170 2 26 0 0 28 0 0 0 0 0 cio msgs:1009 || 85 1 0 48 0 49 170dsp msgs:1039"}
tag v4.2.3:
{"CONTENT":"TIMES","TIME":1699290229,"CLTIME":1695634495,"FTIME":1695634496,"UPTIME":4625614,"PUMPTIME":1149021,"HEATINGTIME":820135,"AIRTIME":0,"JETTIME":5007,"COST":35.89936447,"FINT":14,"CLINT":14,"KWH":448.7420654,"KWHD":448.4306135,"WATT":1942,"T2R":9.688476563,"RS":"Not ready","DBG":" 170 2 27 0 0 29 0 0 0 0 0 cio msgs:75 || 85 1 0 48 0 49 170dsp msgs:74"}
Should I have been changing pin mappings when switching between builds? Is there any further debugging you would like me to try?
@cobaltfish I'll see if I can deduce something from this info. A little busy now but I'll be back.
@cobaltfish new dev version uploaded. I want to see sent messages also, so I added that. Visit layzspa.local/debug-on/ and let it run for a while. Then layzspa.local/debug-off/ Check and post layzspa.local/log.txt
Should I have been changing pin mappings when switching between builds?
No, only when switching between older versions and latest. Don't remember what version though.
and get the trusty old E13 error.
And you restarted the pump and still got this?
Hey,
i'm back from vacation so i had time to test it.
here are my inputs and logs
Edges received on pin D3: 1 Edges received on pin D2: 1 Edges received on pin D0: 0 Edges received on pin D6: 241 Edges received on pin D7: 1 Edges received on pin D0: 0 Edges received on pin D0: 0 On 6-w pump the highest number is CLK, next is DATA and third is CS. On 4-wires the highest is CIO or DSP TX to ESP.
1699395244SW:2023-11-07-2100 CIO-ESP:0,0,0,0,0,0,0,0,0,0,0 DSP-ESP:,FF,FF,0,0,0,0,0,0,0,0,0 ESP-CIO:FF,FF,0,0,0,0,0,0,0,0,0 ESP-DSP:,0,0,0,0,0,0,0,0,0,0,0 1699395520SW:2023-11-07-2100 CIO-ESP:0,0,0,0,0,0,0,0,0,0,0 DSP-ESP:,FF,FF,0,0,0,0,0,0,0,0,0 ESP-CIO:FF,FF,0,0,0,0,0,0,0,0,0 ESP-DSP:,0,0,0,0,0,0,0,0,0,0,0 1699395572SW:2023-11-07-2100 CIO-ESP:0,0,0,0,0,0,0,0,0,0,0 DSP-ESP:,BB,3,0,0,0,3,FD,0,0,0,0 ESP-CIO:BB,3,0,0,0,3,FD,0,0,0,0 ESP-DSP:,0,0,0,0,0,0,0,0,0,0,0 1699395583SW:2023-11-07-2100 CIO-ESP:0,0,0,0,0,0,0,0,0,0,0 DSP-ESP:,BB,3,20,0,0,23,FD,0,0,0,0 ESP-CIO:BB,3,20,0,0,23,FD,0,0,0,0 ESP-DSP:,0,0,0,0,0,0,0,0,0,0,0 1699395584SW:2023-11-07-2100 CIO-ESP:0,0,0,0,0,0,0,0,0,0,0 DSP-ESP:,BB,3,0,0,0,3,FD,0,0,0,0 ESP-CIO:BB,3,0,0,0,3,FD,0,0,0,0 ESP-DSP:,0,0,0,0,0,0,0,0,0,0,0
edit: i also tested the 3.5.1 version wich was last working version for me after 4.1.0 it didn't work anymore
i've pressed some buttons on the display and activated take over and pump/heat on web interface
and get the trusty old E13 error.
And you restarted the pump and still got this?
Yes, I gave it a restart, and it seems to be the "timeout" E13, that it doesn't get data in time, so throws error, rather than the random ones that sometimes get thrown when it has been working well for a while.
I've turned debug on, and pressed some buttons on the web interface, but no response from the unit, even though the web pages show success.
This is the only line line in the debug log.txt
1699433584SW:2023-11-07-2100 CIO-ESP:AA,2,24,0,0,26,0,0,0,0,0 DSP-ESP:,55,1,0,30,0,31,0,0,0,0,0 ESP-CIO:55,1,0,30,0,31,0,0,0,0,0 ESP-DSP:,AA,2,24,0,0,26,0,0,0,0,0
I didn't try pushing the physical buttons, as it was in error mode.
For reference, this is my hardware config page
for completeness sake I ran debug on the 4.2.3 too, and can see the entries from when controlling things in UI:
1699434578:AA,2,24,0,0,26,0,0,0,0,0 ,55,1,0,30,0,31,0,0,0,0,0 1699434590:AA,2,23,0,0,25,0,0,0,0,0 ,55,1,0,30,0,31,0,0,0,0,0 1699434592:AA,2,24,0,0,26,0,0,0,0,0 ,55,1,0,30,0,31,0,0,0,0,0 1699434593:AA,2,25,0,0,27,0,0,0,0,0 ,55,1,0,30,0,31,0,0,0,0,0 1699434596:AA,2,26,0,0,28,0,0,0,0,0 ,55,1,0,30,0,31,0,0,0,0,0
Would running it on dev_v4 with the usb serial monitor give any additional useful info? Its a bit damp here today, so may not be able to do much
Hi @MyMakibox I guess I could. Can you try the latest dev branch version and post two pictures for me: one on your hardware page with the pinouts and one of the results from layzspa.local/inputs/ This page is only available in the latest version. Test with device in pump. Thx
Progress!
Edges received on pin D2: 1 Edges received on pin D5: 1 Edges received on pin D0: 0 Edges received on pin D4: 969 Edges received on pin D3: 1 Edges received on pin D0: 0 Edges received on pin D0: 0 On 6-w pump the highest number is CLK, next is DATA and third is CS. On 4-wires the highest is CIO or DSP TX to ESP.
Sorry for late response but I have very little time over for the moment. Thanks for your posts. @cobaltfish I see you have different models selected in config page. 54144 vs 54154.
Updated dev branch with some more debug info. If you want to run debug-on and post log.txt here again.
here are my new debug logs as before i pressed some buttons on ui and display
1700045492SW:2023-11-12-2000 CIO-ESP:0,0,0,0,0,0,0,0,0,0,0 DSP-ESP:BB,3,0,0,0,3,FD,0,0,0,0 ESP-CIO:BB,3,0,0,0,3,FD,0,0,0,0 ESP-DSP:0,0,0,0,0,0,0,0,0,0,0 cio msg count: 0 dsp msg count: 47 1700045497SW:2023-11-12-2000 CIO-ESP:0,0,0,0,0,0,0,0,0,0,0 DSP-ESP:BB,3,20,0,0,23,FD,0,0,0,0 ESP-CIO:BB,3,20,0,0,23,FD,0,0,0,0 ESP-DSP:0,0,0,0,0,0,0,0,0,0,0 cio msg count: 0 dsp msg count: 57 1700045498SW:2023-11-12-2000 CIO-ESP:0,0,0,0,0,0,0,0,0,0,0 DSP-ESP:BB,3,0,0,0,3,FD,0,0,0,0 ESP-CIO:BB,3,0,0,0,3,FD,0,0,0,0 ESP-DSP:0,0,0,0,0,0,0,0,0,0,0 cio msg count: 0 dsp msg count: 60
Model 54123 PCB v2b
Edges received on pin D2: 1 Edges received on pin D5: 1 Edges received on pin D0: 1 Edges received on pin D4: 235 Edges received on pin D3: 1 Edges received on pin D0: 1 Edges received on pin D0: 1 On 6-w pump the highest number is CLK, next is DATA and third is CS. On 4-wires the highest is CIO or DSP TX to ESP.
1700074110SW:2023-11-12-2000 CIO-ESP:0,0,0,0,0,0,0,0,0,0,0 DSP-ESP:0,0,0,0,0,0,0,0,0,0,0 ESP-CIO:0,0,0,0,0,0,0,0,0,0,0 ESP-DSP:0,0,0,0,0,0,0,0,0,0,0 cio msg count: 0 dsp msg count: 0 1700074125SW:2023-11-12-2000 CIO-ESP:0,0,0,0,0,0,0,0,0,0,0 DSP-ESP:BB,3,0,0,0,3,FD,0,0,0,0 ESP-CIO:BB,3,0,0,0,3,FD,0,0,0,0 ESP-DSP:0,0,0,0,0,0,0,0,0,0,0 cio msg count: 0 dsp msg count: 1 1700074144SW:2023-11-12-2000 CIO-ESP:0,0,0,0,0,0,0,0,0,0,0 DSP-ESP:0,0,0,0,0,0,0,0,0,0,0 ESP-CIO:0,0,0,0,0,0,0,0,0,0,0 ESP-DSP:0,0,0,0,0,0,0,0,0,0,0 cio msg count: 0 dsp msg count: 0 1700074145SW:2023-11-12-2000 CIO-ESP:0,0,0,0,0,0,0,0,0,0,0 DSP-ESP:BB,3,0,0,0,3,FD,0,0,0,0 ESP-CIO:BB,3,0,0,0,3,FD,0,0,0,0 ESP-DSP:0,0,0,0,0,0,0,0,0,0,0 cio msg count: 0 dsp msg count: 1 1700074175SW:2023-11-12-2000 CIO-ESP:0,0,0,0,0,0,0,0,0,0,0 DSP-ESP:BB,3,20,0,0,23,FD,0,0,0,0 ESP-CIO:BB,3,20,0,0,23,FD,0,0,0,0 ESP-DSP:0,0,0,0,0,0,0,0,0,0,0 cio msg count: 0 dsp msg count: 64 1700074176SW:2023-11-12-2000 CIO-ESP:0,0,0,0,0,0,0,0,0,0,0 DSP-ESP:BB,3,0,0,0,3,FD,0,0,0,0 ESP-CIO:BB,3,0,0,0,3,FD,0,0,0,0 ESP-DSP:0,0,0,0,0,0,0,0,0,0,0 cio msg count: 0 dsp msg count: 65 1700074184SW:2023-11-12-2000 CIO-ESP:0,0,0,0,0,0,0,0,0,0,0 DSP-ESP:BB,3,20,0,0,23,FD,0,0,0,0 ESP-CIO:BB,3,20,0,0,23,FD,0,0,0,0 ESP-DSP:0,0,0,0,0,0,0,0,0,0,0 cio msg count: 0 dsp msg count: 91 1700074185SW:2023-11-12-2000 CIO-ESP:0,0,0,0,0,0,0,0,0,0,0 DSP-ESP:BB,3,0,0,0,3,FD,0,0,0,0 ESP-CIO:BB,3,0,0,0,3,FD,0,0,0,0 ESP-DSP:0,0,0,0,0,0,0,0,0,0,0 cio msg count: 0 dsp msg count: 95 1700074190SW:2023-11-12-2000 CIO-ESP:0,0,0,0,0,0,0,0,0,0,0 DSP-ESP:BB,3,20,0,0,23,FD,0,0,0,0 ESP-CIO:BB,3,20,0,0,23,FD,0,0,0,0 ESP-DSP:0,0,0,0,0,0,0,0,0,0,0 cio msg count: 0 dsp msg count: 112 1700074192SW:2023-11-12-2000 CIO-ESP:0,0,0,0,0,0,0,0,0,0,0 DSP-ESP:BB,3,0,0,0,3,FD,0,0,0,0 ESP-CIO:BB,3,0,0,0,3,FD,0,0,0,0 ESP-DSP:0,0,0,0,0,0,0,0,0,0,0 cio msg count: 0 dsp msg count: 116 1700074193SW:2023-11-12-2000 CIO-ESP:0,0,0,0,0,0,0,0,0,0,0 DSP-ESP:BB,3,0,1,0,4,FD,0,0,0,0 ESP-CIO:BB,3,0,1,0,4,FD,0,0,0,0 ESP-DSP:0,0,0,0,0,0,0,0,0,0,0 cio msg count: 0 dsp msg count: 118 1700074209SW:2023-11-12-2000 CIO-ESP:0,0,0,0,0,0,0,0,0,0,0 DSP-ESP:BB,3,0,0,0,3,FD,0,0,0,0 ESP-CIO:BB,3,0,0,0,3,FD,0,0,0,0 ESP-DSP:0,0,0,0,0,0,0,0,0,0,0 cio msg count: 0 dsp msg count: 148 1700074218SW:2023-11-12-2000 CIO-ESP:0,0,0,0,0,0,0,0,0,0,0 DSP-ESP:BB,3,20,0,0,23,FD,0,0,0,0 ESP-CIO:BB,3,20,0,0,23,FD,0,0,0,0 ESP-DSP:0,0,0,0,0,0,0,0,0,0,0 cio msg count: 0 dsp msg count: 168 1700074222SW:2023-11-12-2000 CIO-ESP:0,0,0,0,0,0,0,0,0,0,0 DSP-ESP:BB,3,0,0,0,3,FD,0,0,0,0 ESP-CIO:BB,3,0,0,0,3,FD,0,0,0,0 ESP-DSP:0,0,0,0,0,0,0,0,0,0,0 cio msg count: 0 dsp msg count: 182 1700074223SW:2023-11-12-2000 CIO-ESP:0,0,0,0,0,0,0,0,0,0,0 DSP-ESP:BB,3,0,1,0,4,FD,0,0,0,0 ESP-CIO:BB,3,0,1,0,4,FD,0,0,0,0 ESP-DSP:0,0,0,0,0,0,0,0,0,0,0 cio msg count: 0 dsp msg count: 185
Edges received on pin D2: 1 Edges received on pin D5: 1 Edges received on pin D0: 1 Edges received on pin D4: 255 Edges received on pin D3: 1 Edges received on pin D0: 1 Edges received on pin D0: 1 On 6-w pump the highest number is CLK, next is DATA and third is CS. On 4-wires the highest is CIO or DSP TX to ESP.
Hardware:
Software:
Your message Spa works and has worked perfect for months and years, just got it ready for Summer - working fine on the "old - split" firmware, 4W_2022-08-03. Tried out the new unified firmware following the instructions and wiping my ESP8266, but getting a "04" or "39" on the CIO depending on the temperature unit, and no response from the pump by either Web GUI or buttons.
Did the Hardware test and it states all pins failing (I think there is a typo in the hardware test output stings, as it states pins 3,4,5 and then 3,4,5 again in the code, not 0,1,2,3,4,5?).
Re-installed Firmware 4W_2022-08-03 and the spa works again fine via buttons and Web GUI again.
I've skimmed through the code and am unsure what may be causing this, but it's like the pin mappings are all out for me on the newest version? I'd love to be able to be on the latest revision and take advantage of the new GUI, HA entities and the firmware updates etc. Any pointers, as its most definitely NOT a hardware issue, despite the HW test stating all lines are down? Is it the level shifter having issue with the new firmware (seems unlikely)?