CN-WIRED ongoing work. #240
Comments
This is a surprise-surprise! I've dug down my archives and found raw_sampler dumps made by @dremugit. Here they are: Air conditioner sending once per second to emptiness, no wall panel attached: (every second packet is trimmed due to limited buffer space) Hah, indeed. Ones are 980 usecs... Here are some wall panel "replies": Ones are about 940 usecs... This is what i took from my "Daichi" 3rd party cloud controller; the only thing i personally have on hands. That's where i took 900 us from: We clearly see there's no "DELAY END" sequence here. This all completelly baffling. It seems that the protocol is actually super-tolerant. Damn, i have no idea why our tx doesn't work. Especially knowing, that tx code in my Arduino bridge DOES work, two people have confirmed that. There aren't many variables here, really. We are just totally blind... We miss a ve-e-e-e-ry tiny detail. Unfortunately Glinka has stopped giving me feedbacks, and i have nobody else to test with, I intentionally don't copy everything you're doing because it makes much more sense to try different things. Also i would suggest to ignore new packet types for now. I think that perhaps they have come to the same conclusion as we did: not reporting actual state sucks; and checksum algo is LOL. They tried to fix this by extending the protocol in backwards compatible manner. As to unknown bytes [1] and [2]; there definitely should be some capability flags. The AC must have way to indicate which optional features it supports (like H/V swing, LED control, etc). These flags must come with packet type 0, because that's the only data sent regularly. We can try correlating data in those packets to AC models and features they have. But that's low priority; we need to beat tx. We're definitely doin' it wrong(tm); and this wrongness is damn simple. |
|
By the way, those who aren't afraid of Arduinos, can do two-way dump right now:
Note this is an old dump; newer version will add microsecond timestamp to each packet, so that they can be correlated in time. Timings, if enabled, will look like long string of numbers. Something like: (this isn't a real example, i made it up because i only used it to calibrate my own ESP8266 tx routine, and never saved such logs) |
|
I could perhaps be electrical? Does anyone using a Faikin board on CN_WIRED have an oscilloscope they can use to check Tx? The board was designed for serial, where the Daikin has internal pull ups, so is driven open drain. But if there is not a pull up, then we need to ensure the 5V is connected to there Faikin board to pull up. |
|
@revk Good thing to check. You may look at schematic of "Daichi" controller in my repo under Hardware/; maybe this will give you some hints. I agree that Tx circuit looks weird; but i rechecked 10 times; Q1 indeed goes to Vcc, and R2 indeed goes to Vio, which looks like +5V. I have no idea how the line is brought down. Perhaps i guessed Q1 wrong; the transistor is unmarked, i simply tried to pick by footprint something that made the most sense. Maybe that gives you some ideas. Anyways, this circuit does have pullups. |
|
Well it also depends if the 5V has been connected to the Faikin. A scope on the Tx would help. |
|
!!! BREAKING NEWS !!! IT WORKS !!! https://github.com/Sonic-Amiga/ESP8266-Faikin commit 6e7f267 - this is known working version @revk If you do everything exactly the same way; the only possible problems are indeed electrical. I will continue trying to improve the implementation; disabling interrupts on a running OS feels very harsh; But, anyways, we've got known working implementation. |
|
It would help to know if existing testers have 5V connected, and if any have a scope. |
I have 5v connected but do not have a scope, unfortunately. I can say that receiving does seem to work (though it does not seem like the mode is necessarily accurately reflected--I have mine running on Auto (not Faikin auto) and it's showing set as cool, but I'm looking at it right now and it's heating. Happy to connect it to another MQTT server if it's helpful for debugging. |
|
Well, connecting to |
I assume not, but anything I could do with a standard multimeter to help? |
|
I doubt it, it works some times, so likely signal timing with the 10k pull up not being enough or some such. |
|
Hello everyone! Recent experiment proved that 16ms delay, then 2ms low pulse after the packet is mandatory. Without them the conditioner does not accept the packet.
I am on a short trip for 2 days. See my git log and driver code for more info. It has been verified to work.
Also pay attention to recent commit regarding swing control. Apparently "Daichi" controller , from which i derived the protocol, doesn't get it 100% right.
I will update the documentation when i come back
…On Feb 21, 2024, 18:14, at 18:14, RevK ***@***.***> wrote:
I doubt it, it works some times, so likely signal timing with the 10k
pull up not being enough or some such.
--
Reply to this email directly or view it on GitHub:
#240 (comment)
You are receiving this because you were mentioned.
Message ID: ***@***.***>
|
|
My code does the 16ms high, 2ms low, at the end, already. Hmm. |
|
And you also have a 10K pullup; totally the same as Daichi board has... |
|
So, i switched TX back to timer interrupts; and it all works fine. The only thing i had to keep is 16ms high, 2ms low termination sequence. |
|
Updated the protocol doc. Please pay attention to swing control details; appears quirky. |
|
For my own reference |
|
Hello guys! |
|
is this still on thé table? |
|
We got a bit stuck really. Recreating the protocol, but seems not to play. We can receive. |
|
We are assuming there's an electrical incompatibility in Faikin board. And i've got an idea how to verify this. My ESP8266 port works great on its original target HW; my user Glinka65 is happy. So, what if we take a Faikin board and transplant a 8266 module onto it ? My board is built around ESP-12F; so that's just 100% known to work. Flash with my firmware and try. If the issue persists; it's indeed electrical problem. If not - the code is broken and we're missing something out; just look real carefully. Yes, requires electronics skills. Also i have recently purchased an ESP-32S-based devboard; so i'll be able to play with the firmware on my side. But i don't have an actual A/C; only a simulator; and Glinka doesn't live in my city so we can't meet up for hands-on testing. Sorry for my own disappearance. I was attacked by sheer laziness after the vacation. |
|
Equally my code on a board with 5V level shifters may work. |
|
Looked at Faikin schematic once again... Indeed, it's possible that pull-up on TX line (from Faikin to AC) is missing. And the fix could be as simple as connecting pins 1 and 4 of Faikin connector together. !!! Before doing this, make sure that power supply voltage from the AC is 5V and no more !!! |
|
Evening all. specs I have a unit that only has CN-WIRE connection. I made a cable using info found on this site and connected up the ESP32 device. Erasing then Flashing the ESP32 device with the latest beta or main release firmware using the below commands allowed the unit two boot and operate correctly.
then
After I configured the TX and RX GPIO to TX = 1 and RX = 3. Then I set the settings to only use CN-WIRE but I continue to have offline message on the web interface. But when I use the remote to change any setting the web page is updated in real time. I hooked my oscilloscope up to TX pin of the ESP32 and I get nothing when changing settings on the webpage or operating the remote. Tried a 10k pull up on TX pin, still nothing....I have tried changing many settings and different GPIO pins (some prevented boot) but still nothing makes the TX pin work! If I connect my oscilloscope to the RX pin I get output from the unit every second and when using the remote. So why do I get nothing on TX pin and the web page shows offline? Thanks. |
|
I am not sure we finally crasked it, but you should see data sent! |
|
Ok so I figured maybe my esp32 device was bad or non compatible in some way, so I switched to a ESP8286 device "ESP8266 ESP-12 ESP-12F NodeMcu Mini D1 Module WeMos Lua 4M Bytes" and uploaded branched firmware from here set TX = 1 RX = 3, selected only CN-WIRE for protocol and it is working! So not sure if its the hardware or the firmware...Thanks Edit to add the programming commands
|
|
Small note. My port ignores rx/tx pin setting; those are hardcoded to 3 and 1 because that's the only valid choice. In 8266 they aren't reprogrammable. |
|
@lank23 Can you describe your HW setup more precisely ? Have you taken your Faikin board and transplanted a 12F onto it; or have you done something else ? "Offline" means you aren't receiving any data. CN-WIRED ACs don't need to be actively queried, they just send status once per second. So you should at least see data coming from the AC, and the controller should be able to decode and display current status once you control the conditioner using its remote. Nice to hear that my port works for someone else, however |
|
Weird, I'll look. |
|
I have rebuilt and checked from my units that beta is OK loading now. |
|
strange for me it keeps failed |
|
Do you know what IP you would be coming from, I can check logs. But popping out for a bit right now. |
|
Can i send it to you in private? would not expose my IP to the whole world :-) |
|
LOL, you do on every packet you send, but not sure best way. I checked logs and saw no errors. Can you lot network traffic to determine why it fails? |
|
ok, ive managed to update via hotspot indeed there is something blocking the server When i use the remote everything is changing, but when i change someting in the web screen nothing happens
|
|
Aha. |
|
@revk I think you closed it too early. |
|
And i've got a question for you. You encode CN_WIRED_SYNC as two consecutive symbols; which implies there's a limit of 1000 us. Then how come you encode CN_WIRED_IDLE as a single symbol of 16000 us ? |
|
I don't remember, I think it was based on timings people made. |
|
@revk You perhaps didn't get the exact question. Why this: instead of just one full-length interval ? If you repeat "don't remember" that's okay; i actually have possibilities to play with this myself. |
|
Well it is a once sided pulse or something, I do forget. |
|
I checked; and tx (Faikin -> AC) stops working with simulator if i try to encode start bit as just one symbol. |
|
So far, all protocol code is the same between 8266 version (which we know works) and ESP32. I verified all timings again, it's all good. My ESP32 devboard works great with my simulator. The only option left is HW incompatibility. And with the latest board that should be simple. @type-rke Are you brave enough to try a simple hardware mod ? You need to connect together pins 1 and 3 on Faikin connector. Assuming the board is latest revision. Something like this:
|
|
Did not do anything except my faikin gets warm so i disconected, will it fry? |
|
what is strange, back in ferbuary i was able to control for 2 days now i can only do a readout, so it was working back then |
|
this is my board, is it OK that i connect these together?
|
|
Where is pin1 (marked 5V) connected to ? CN_WIRED connector only has 4 pins. The board itself looks proper. To double-check, this pin should only be connected to a resistor on the board and nothing else. Other end of that resistor sits on the power line (marked +12V). |
Wow, so did we have a success ? I guess we missed that. Thank you for the info, we'll definitely be able to figure it out. |
i have 5 pins on CN Wired |
|
Huh... And that explains how you actually got it working. |
|
here you see i mention that not all functions are working, but some are for at least 1 day If i remember correctly there was a beep every time i changed something in the web app , but the swing function did not work That was why i asked for a rolback firmware to the 5 or 6th of feb |
|
I read that. Not all functions isn't a problem; i backported all high-level code from 8266, so now all functions are there. The only problem is something in the cn_wired driver. I'll check git log. |
Frankly speaking i didn't expect a 5-wire connection. I expected 4 wires. Now, before continuing any HW experiments, please verify that:
And could you draw AC side of the connection ? Actually the experiment i suggested assumed that there is 4-wire connection, exactly as shown on my drawing. I. e. Faikin pin 1 (pullup) is connected to Faikin pin 3 (tx) and nothing else. |
|
Can i also somehow see your advanced settings ? I am particularily interested in:
Note that we're talking about ESP32 board here. We know 8266 works perfectly. |
|
Since you say that on 7 Feb it worked, another activity is possible. And only you can do it. Look at git history from 4024801 to 64217f3 . From the log you can see there were many changes (all regarding cnw) and many betas released. Can you try some of them and find any version that works for you ? And tell me commit it ? I'll be able to see the differences and fix master. Unfortunately at the moment only you seem to be willing to help. Yes, that's a lot of work, we'd appreciate. Note that when flashing these betas you also need to disable automatic upgrades. If you don't, Faikin will soon revert itself to the latest version. Thank you in advance for your great help. |
|
I would like to try the older versions, however i need some help (howto ) flash these firmwares to test them again |
Closing #126 to start again as far too long - let's start again.
Where are we?
We have details of low level timings and codings, and dumps of messages both ways, and a good idea of the protocol. A lot done by @Sonic-Amiga researching. However, we have seen some variations which even have a different checksum system.
This Faikin s/w now has CN_WIRED which can be enabled by turning off the new
nocnwiredsetting. It has basic sending and receiving of messages, but it seems sending is not entirely reliable with sent messages actually working. Given how well the low level timing is understood, this seems protocol (byte level) as a likely issue, and we do not understand all the bytes. Interestingly @Sonic-Amiga has seen 900uS mark, but others have recorded 1000uS mark, including my testing with @akifrabbaniWe now have new settings in Faikin...
cnsend4Causes 4 sends of packets when sent instead of 1cnmark900Causes use of 900uS mark not 1000uScnbyte1Allows byte 1 in sent message to be set (in hex)cnbyte2Allows byte 2 in sent message to be set (in hex)I can add more settings and options. I expect to remove these once properly cracked.
Setting
nos21andnox50aandnoswaptxandnoswaprxand unsettlingnocnwiredforces CN_WIRED and no others.The text was updated successfully, but these errors were encountered: