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 |
|
Guys, some of you, i recall, said that you have an original Daikin wi-fi boars, which plugs into that connector. Can anyone remove it and make high-quality photo, or better scan, or both sides ? I want to try reversing it in order to better understand the interface. |
Can you send us some MQTT logs ? Interesting because nobody has reported this problem on 8266, and code is the same. And let's keep it a separate issue #409 in order to avoid flooding. |
Yes, when i measure this it is 4.97v and the board will not start, with 12v its starts without issues |
|
FYI Faikin is good down to 4V for power (and up to 36V), so the issue will be current. But a 5V reference can be used as the pull up, and is probably what it is for. |
|
@type-rke Let's also clarify pins on AC side. Is this picture correct ? Is that one 12V ? I talked to Glinka65, whose request started all this. I was wrong, CN_WIRED is always 5 pins. |
|
On mine, CN_WIRED is indeed
12VRxGndTx5V
An interweb tells me that the ESP32 chip proper can draw up to ~250mA. Believe that as much as anything you find on an interweb.
I can say that mine, wired to the 5V, runs happily. Again, it's a Node32S knock off with that MOSFET level convert and no LED's (I desoldered the power LED from the board as the missus hates what she calls "light pollution".) I'd assume, then, that my board isn't pulling much more than that ~250mA.
Hope that's informative.
-- A
On Saturday, August 3, 2024 at 11:46:59 AM PDT, Pavel Fedin ***@***.***> wrote:
@type-rke Let's also clarify pins on AC side. Is this picture correct ? Is that one 12V ?
image.png (view on web)
I talked to Glinka65, whose request started all this. I was wrong, CN_WIRED is always 5 pins.
But Daichi controller indeed connects to 5V with its official cable. Interesting. Perhaps ESP32 has a larger current draw.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
Thank you very much; that's enough of info. |
|
I have boards coming to test with a pull up on the Rx side, if someone with CN_WIRED is in UK I could send a sample. |
|
Hi, a have succesfully tested ESP8266-Faikin on FTXN25JXV1G units equipped with cn_wire connector. The 5-pin connector pinout is 12VRxGndTx5V. I have also tested the sleep mode available in this units. This mode is entered sending the special mode 0x20. Maybe this mode can be included in future releases. |
|
Interesting. |
|
Hi! I have just returned from vacation, hope get my hands back on project this weekend. I will add support. |
|
@revk i guess you can default this protocol as "enabled" on Faikin32 |
|
Acording to the user manual sleep mode does:
|
|
Aha, i know this function; seems all those units have it. |
|
That's correct, I added: #define CNW_SLEEP 0x20 In cn_wired.h and if (daikin.sleep) In Faikin.c., line 864 By the way, for the comments on CNW_V_SWING near line 858, I can confirm that it works on my unit. |
|
So do you already have a patch? |
|
Yes! Please tell me how I can provide it! |
|
From your question i conclude you have never forked projects and published PRs. In fact that's easy:
If you find this difficult for whatever reason, you can simply attach output of 'git diff', i will apply that |
|
You are right, i've never published PR :) I' ve followed your indications and I think i'ts done. |
|
@ghpazo Hi! Sorry for my silence, too much stuff to do plus quite difficult re-acclimatization back from +28 to 0C :( I am too sleepy... @revk WDYT ? |
|
Whatever people think best |
|
@ghpazo Hello! Thank you very much for your contribution! I thought for some more, and merged your patch as it was. After all, "Sleep mode" and "Comfort mode" are very different functions. I only adjusted value for VSwing from 0x70 to 0x50, so that it doesn't clash with the newly discovered bit. I released a beta, you can find it in the repo or download it from my second update server: http://faikin-ota.home-assistant.my/ . Please check.
What exactly works? Swing mode ? It should, because we figured it out with Glinka65, my first user who kickstarted CN_WIRED effort and helped with reverse engineering electrical part. You know what, if you are coding, could you help figure out, which of remaining two bits actually enables swing ? 0x10 did not work with Glinka, so we simply left it as 0xF0 back then (there was no LED control yet). Note also buf[6] in daikin_cn_wired_send_modes() The behavior currently implemented was copied from 3rd party "Daichi" controller; that's the only reference i had. Maybe you have some original Daikin equipment, which plugs into this port, like wired wall control panel ? |
|
And sorry for terrible delay; i lost my sleep, no idea why, just seem to more or less recover. |
|
Hi, I'm sorry for the delay, I've been out for a couple of days. I've tested the beta and it worked fine. I don't have a daikin controller which plugs into that port, all the info I could get is analyzing the unit response to commands sent by the ir controller. I've tried setting the on, off timers, triggering an error, diagnostic mode, etc but that info seems no to be sent to the cn_wired port. As for the swing mode, I've done some tests and on my unit the only bit that enables it, is bit 0 of 6th byte. Changing the other bits in CNW_SPECIALS_OFFSET doesen't seem to change swing mode or any other visible features. Acording to the IR remote user manual, some units have 3 swing modes, full, upper and lower, maybe the other bits control that. Please let me know if you want me to do more tests. |
|
I've been recently testing a Faikin connected to CN_WIRED on my Diakin FTXB12AXVJU Mini Split. Seems to be working just fine. Thanks for all the hard work! However it was a challenge to figure out the wiring for this connector since it is not listed on the main documentation. I was wondering if CN_WIRED support is considered stable enough to document it on the Wiring page. There are also no models listed on the List of confirmed working air con units that mention the CN_WIRED connector. I would be willing to make these changes if you agree. |
|
To be honest, you are in the best position to say if it works, as I have no CN_WIRED devices. Happy for a pull request or just suggestions for adding to wiring page. |
|
@mikelawrence Hello! I guess it's stable, just it appears to be quite rare, we don't have many users. |
|
@revk I'm not a strong GIT user and forking Faikin does not include the Wiki so I couldn't use a PR, but Github allowed web based Wiki modification. So that's what I did on the Wiki Wiring page. If I have overstepped my bounds or breached etiquette by all means scrap the changes. |
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: