ユーザー名:

パスワード:


パスワード紛失

新規登録
ビートス オンラインショップへ
アブソリュート株式会社様へ

ダイキンのエアコンで動作一切不可

前の投稿 - 次の投稿 | 親投稿 - 子投稿.2 .3 .4 .5 .6 .7 .8 .9 | 投稿日時 2017-10-9 22:53
warp  <ROOKIE>   投稿数: 8
我が家のダイキンのエアコンのリモコンは、ファームウェア2.1.6系でも
学習することができません。

状況としては、こちらで報告されているものと同じです。ただし、2.1.1ではなんとなくコードが取得できているものの、2.1.6系ではそもそも取得自体ができません。
http://a-desk.jp/modules/forum_hobby/index.php?topic_id=86

ファームウェア3系でキャプチャした結果はこちらです。
https://pastebin.com/z2mVeNyw

データフォーマットを解析された方がおられて、確かにそのようになっているようです。
http://blog.fchiba.net/archives/172484.html
(リンク先では「“bit 0”×6回+ストップ信号」となっていますが、これは5回の誤りだと思われます)

こちらのフォーマットへの対応は難しいでしょうか…?
イイね!の数:0
返信する
前の投稿 - 次の投稿 | 親投稿 - 子投稿なし | 投稿日時 2017-10-11 23:24
warp  <ROOKIE>   投稿数: 8
ログインせずに投稿してしまったのでもう一度。

「USB赤外線リモコンアドバンス」の方も手に入れて、同じダイキンの
エアコンのリモコンで試してみました。

結果は、純正のWindows版ツールでは問題なく学習できましたが、
Linux版ツール bto_advanced_USBIR_cmd では、それっぽいコードは
取得できるものの、それを発信してもエアコンを操作することは
できませんでした。
イイね!の数:0
返信する
前の投稿 - 次の投稿 | 親投稿 - 子投稿.1 | 投稿日時 2017-10-12 6:29
disklessfu  <EXPERT>   投稿数: 198
これはmsg# 1.2に対するレスです。

私は bto_advanced_USBIR_cmd の作成者です。

bto_advanced_USBIR_cmd は 純正の、USB_IR_Library_v4.1.0をC言語にポーティングして作成したものです。

USB_IR_Library_v4.1.0は 2年前に公開された最初期版の純正ライブラリです。

残念なことにビット・トレード・ワンさんは、以降のバージョンでソースを公開しなくなりました。

なので、仮にwarpさんがアドバンスを最近入手されたのだとすると、
warpさんがbto_advanced_USBIR_cmd を使うということは、
最新ファームウェアのアドバンス(本体)と古いライブラリを組み合わせで使用している状態に近い
可能性が高いと思います。

ただし、「それを発信してもエアコンを操作することはできませんでした」の原因が、ポーティング元ソースの古さに
あるのではなく、私がオリジナルで書いた部分にある可能性もおおいにあります。

取得された“それっぽい”コードを公開して頂ければ、(このスレに貼る等の手段で)
私は、私オリジナルの部分に問題があるのか、ポーティング元ソースにあるのかを検証することができるかと思います。

でも検証が成功しても、アドバンスはファームウェアのソースが一貫して非公開なので、ポーティング元ソースに問題があることが判明した場合は
どうすることもできません。

あと、アドバンスのファームウェアが、現在販売されているものやwarpさんが持っているものと、(私が持っている)初期に販売されているものとで、異なる可能性があると思います。だとすると、検証は失敗するかもしれません。
イイね!の数:0
返信する
前の投稿 - 次の投稿 | 親投稿 - 子投稿.1 | 投稿日時 2017-10-12 6:30
disklessfu  <EXPERT>   投稿数: 198
これはmsg# 1に対するレスです。

私は2.1.6系の作成者です。

まず、簡単に申し上げますと、今までに公開されたVer. 2.X.Xファームウェア全ての中に、
warpさんのところの、(わりと新しめと思われる)ダイキンエアコンに対応するものが“あるはずがない”と思います。

(ところで、2.1.1というバージョンは過去に見たことがあるような気がするのですが、今現在はどんなものか把握していません。
 ファイルアップローダにないようです。、どこかのスレに外部リンクが貼ってあるのだと思いますが、今はそれがどこにあるかわかりません。
 でも純正2.1.0の小改造版であることはほぼ確実だと思います)


Ver. 2.X.Xファームウェアは、内部に定義されたフォーマット以外は全く対応できないタイプのファームウェアです。
しかもビット・トレード・ワンさん純正のファームウェアによって定められたコード化の方式では、データ分割なしか、2分割にしか
対応できません。warpさんのところのダイキンエアコンは4分割かつ不等長なので、明らかに未対応です。


2.1.1でなんとなくコードが取得できるそうですが、純正の2.1.0がダイキン(多分、warpさんのよりずっと古いダイキンエアコン)対応
を謳っているので、その名残で、一部のコードが取得できるのでしょう。


2.1.6系で取得できないという情報は今回初めて知りましたが、予想はできていたことです。
2.1.6系zip内xlsxの、ダイキンのフォーマットのシートが白紙なのでわかるとおり、私はダイキンエアコンのフォーマットデータを全く持っていませんでした。
なので、過去の私が公開したVer. 2.X.Xファームウェア全てにおいて、ダイキンエアコンについては一切のテストをおこなえていません。
あれだけ(私が)大改造するなかで、異端的なフォーマットのダイキンエアコンのコードが取得できない(できなくなる)のは、ある意味当然のことだと思います。


以前に、ビット・トレード・ワンさんに、「お手持ちのダイキンエアコンのフォーマットデータを公開して欲しい」とメールしましたが、反応はありませんでした。


2.1.6系zipの中にナショナル(現パナソニック)エアコン対応専用板があります。
これはコード化の方式も他とは異なる専用板となっています。
同様の方式で、warpさんのダイキンエアコン専用板を作ることは可能と言えば可能でしょう。
(もちろんそれはVer. 2.X.Xファームの一員なのでLinux,MacOSで使えます)
イイね!の数:0
返信する
前の投稿 - 次の投稿 | 親投稿 - 子投稿なし | 投稿日時 2017-10-13 0:42
warp  <ROOKIE>   投稿数: 8
>(ところで、2.1.1というバージョンは過去に見たことがあるような気がするのですが、今現在はどんなものか把握していません。
> ファイルアップローダにないようです。、どこかのスレに外部リンクが貼ってあるのだと思いますが、今はそれがどこにあるかわかりません。
> でも純正2.1.0の小改造版であることはほぼ確実だと思います)

http://bit-trade-one.co.jp/support/download/

こちらにある

・最新ファームウェア(Ver2.1.1) [RemoconServant211]
・ファームウェアソースコード(Ver2.1.1) [RemoconServant211]

が現在の公式の最新版ではないでしょうか…?
イイね!の数:0
返信する
前の投稿 - 次の投稿 | 親投稿 - 子投稿.1 | 投稿日時 2017-10-13 0:57
warp  <ROOKIE>   投稿数: 8
disklessfu さん、レスありがとうございます。

>取得された“それっぽい”コードを公開して頂ければ、(このスレに貼る等の手段で)
>私は、私オリジナルの部分に問題があるのか、ポーティング元ソースにあるのかを検証することができるかと思います。

以下が、問題のダイキンエアコンのオフ命令を bto_advanced_USBIR_cmd で受信した結果です。

https://pastebin.com/KJMxfenB

同じものを、Windows の ADIR01P_Trns_CT_v12.zip で取得するとこうなります。

https://pastebin.com/TEeQt7p5
イイね!の数:0
返信する
前の投稿 - 次の投稿 | 親投稿 - 子投稿.1 | 投稿日時 2017-10-13 0:58
warp  <ROOKIE>   投稿数: 8
ちなみに、私が購入した USB赤外線リモコンアドバンスの
ファームウェアバージョンは 1.3.2 でした。
イイね!の数:0
返信する
前の投稿 - 次の投稿 | 親投稿 - 子投稿なし | 投稿日時 2017-10-27 22:19 | 最終変更
disklessfu  <EXPERT>   投稿数: 198
遅レスですみません。

アップして頂いたデータを用いて、アドバンス、bto_advanced_USBIR_cmdを
ごく簡単に検証してみました。

当方手元にあるアドバンスは発売当初のものです。
でも、ファームウェアバージョンwarpさんと同じ1.3.2と表示されました。
※ファームのバージョンはUSB_IR_Remote_Controller_Advance_Trns_CT.exeで取得しました。
でも今回、Windows用ソフトを用いた場合の動作検証はまだ全くおこなっていません。



ソースを調べない、ごく簡単な検証作業しかしていないんですが、
見かけ上は、後述のように、ファームウェアにバグがあるような症状が確認されました。

でも同じファームウェアバージョンであっても、Windows用の最新ツールから使えば、その症状は出ないという
ことなので、もしかすると、まだ使ったことのない関数なんかがあって、それを使ってファームウェアの
設定を調整してやれば、解消する問題なのかもしれません。
でもライブラリの取扱説明書r03にそのような記述はありません。
可能性があるとすれば、一旦コードで出力する関数を使用すると、後の動作が変わるとか…


ここからは検証作業の具体的な記述です。

まず、アップして頂いたADIR01P_Trns_CT_v12で取得したコードをbto_advanced_USBIR_cmdに与えると
どうなるかを確かめました。

かなり正しく出力しました。
(2017年11月8日、このパートは削除しました。検証作業の勘違いの為、問題がないのに、問題があると書いていた為です)





次に(手抜きをして)、bto_advanced_USBIR_cmdで取得したコードとADIR01P_Trns_CT_v12で取得したコードを
机上で比べました。

bto_advanced_USBIR_cmdで取得したコードは、本来はトータルで583個のON・OFFがなければいけないのに、
先頭から144個目で終わっています。

でも、その144個目までの値はADIR01P_Trns_CT_v12で取得したコードとデジタル的には一致しています。

長いOFFの取扱いで問題が生じているようです。
(2017年11月8日、前パートと絡めた記述を削除)





ADIR01P_Trns_CT_Code_v12.zipの中の、USB_IR_Remote_Controller_Advance_Trns_CT.exeを用いての
動作検証は、テキストの変換が面倒なのでおこなっていません。


warpさんがアップされたADIR01P_Trns_CT_v12で取得したコードは、bto_advanced_USBIR_cmd用に
フォーマットを変換して下さっていたわけですね。


お手数ですが、変換前の、USB_IR_Remote_Controller_Advance_Trns_CT.exe用のテキストデータを
アップして頂けないでしょうか
私の方で逆変換することも可能といえば可能ですが、USB….exeに慣れていないこともあり、
warpさんに頂いた方が確実だと思います。


そのデータをUSB….exeで出力してみたいです。
もしその出力に異常があれば、ファームウェアが、バージョンがの数字が同じでも、実は中身が違うということになるかと思います。
もし正しく出力されれば、ファームウェアはバージョン表示どおり、発売当初から変更されていない可能性が高いということになると思います。

ちなみに_IR_Remote_Controller_Advance_Trns_CT.exeはライブラリを使用していないようです。
ソースを読めば、いろいろわかることがあるかもしれません。
イイね!の数:0
返信する
前の投稿 - 次の投稿 | 親投稿 - 子投稿なし | 投稿日時 2017-11-4 22:45 | 最終変更
disklessfu  <EXPERT>   投稿数: 198
2017年11月8日、内容を削除しました。

検証のミスでした。
イイね!の数:0
返信する
前の投稿 - 次の投稿 | 親投稿 - 子投稿.1 | 投稿日時 2017-11-6 0:05
warp  <ROOKIE>   投稿数: 8
レスが遅れてすみません。

> warpさんがアップされたADIR01P_Trns_CT_v12で取得したコードは、bto_advanced_USBIR_cmd用に
フォーマットを変換して下さっていたわけですね。

いえいえ、ADIR01P_Trns_CT_v12.exe で受信して、「クリップボードでコピー」したものをそのままpastebinに貼り付けました。

なお、他の方が作られた Linux 用ツールを発見しまして、そちらでは同じダイキンのエアコンのリモコンコードが記録・送信できているようです。

https://github.com/sakapoko/adir01p

こちらのツールで同コード(エアコン・オフ)を記録したものは、以下のようになります。

https://pastebin.com/3F1w2Fue
イイね!の数:0
返信する
前の投稿 - 次の投稿 | 親投稿 - 子投稿なし | 投稿日時 2017-11-7 0:20 | 最終変更
disklessfu  <EXPERT>   投稿数: 198
実は一昨日、USB_IR_Remote_Controller_Advance_Trns_CT.exe(ADIR01P_Trns_CT_v12)を使った際に、
フォーマット変換は必要ないことに気づきました。
でも、テキストを読み込ませて送信する方法がわかっていないので、まだ報告していませんでした。
報告が遅れてお手数をかけました。すみません。

検証はまだおこなえていません。
その為には正しい赤外線命令を送信可能な他のツールが必要です。

手持ちのlircで送信できるんですが、lirc送受信機のケースには受信用の穴しか開けていないので、
送信する為には固定を外してケースから基板を取り出す必要があります。
それが面倒なのでまだやってません。

また、warpさんがアップされたデータをADIR01P_Trns_CT_v12から送信し、
lircで計測することにも意味がある筈ですが、前述のように送信の方法が
まだわかっていません。そもそも送信可能かどうかもまだわかっていません。

という状況です。

今までのところ
https://pastebin.com/KJMxfenB
は途中でデータが終わっていて、
https://pastebin.com/TEeQt7p5
の方では最後までデータが取得できている理由が全くわかりません。

受信処理自体は完全にハード側でおこなっていて、
ADIR01P_Trns_CT_v12であろうとLinuxのツールであろうと、後で結果を受け取るだけなので、
「ツールの違いによって、長いオフの受信において問題が発生したり、しなかったりする」するという
事態は原理上、普通発生しえないからです。

実際にはそれが発生するのなら、かなり複雑な事情が関係しているとしか考えられません。

もしくは、warpさん、失礼ながら
https://pastebin.com/KJMxfenB は https://pastebin.com/TEeQt7p5 と比べると、途中で切れるまで
デジタル的に同一なので、何らかの偶発的な不具合(作業ミスとか?)で途中で切れただけなのではありませんか?


ちなみにhttps://pastebin.com/TEeQt7p5https://pastebin.com/3F1w2Fue
はデジタル的に同一でした。
(2017年11月8日追記:↑これは誤り。msg# 1.8にも記述)
イイね!の数:0
返信する
前の投稿 - 次の投稿 | 親投稿 - 子投稿なし | 投稿日時 2017-11-8 0:47
warp  <ROOKIE>   投稿数: 8
> もしくは、warpさん、失礼ながら
> https://pastebin.com/KJMxfenB は https://pastebin.com/TEeQt7p5 と比べると、途中で切れるまで
> デジタル的に同一なので、何らかの偶発的な不具合(作業ミスとか?)で途中で切れただけなのではありませんか?

念のため、bto_advanced_USBIR_cmdで当該コードを再度5回ぐらい繰り返して
受信してみましたが、「取得したbyte配列の要素数」の値は毎回288なので、
偶発的な不具合や作業ミスによって途中で切れたわけではないと思います。
イイね!の数:0
返信する
前の投稿 - 次の投稿 | 親投稿 - 子投稿なし | 投稿日時 2017-11-8 21:34 | 最終変更
disklessfu  <EXPERT>   投稿数: 198
warpさん、いろいろありがとうございます。


急転ですが、全て解決しました。


まず、先日から私が「当方手持ちのバージョンでは送信に問題がある」と騒いでいましたが、
これは、全くの勘違い、というか、検証作業のミスでした。表計算シートの計算式のミスでした。
どのツールを使っても送信に問題はありませんでした。


次に、warpさんから指摘の、ダイキンエアコンだと bto_advanced_USBIR_cmd での受信に問題が発生する件ですが、

やはりmsg# 1.3.1.1.1に書いた
>でも同じファームウェアバージョンであっても、Windows用の最新ツールから使えば、その症状は出ないという
>ことなので、もしかすると、まだ使ったことのない関数なんかがあって、それを使ってファームウェアの
>設定を調整してやれば、解消する問題なのかもしれません。
>でもライブラリの取扱説明書r03にそのような記述はありません。
このような線の問題でした。


症状は正確には、「先頭以外で30msを越えるON、もしくはOFFがあると、そこで受信が終了する」
というものでした。

これは、bto_advanced_USBIR_cmd のポーティング元ソース、USB_IR_Library_v4.1.0 の時点で既に、
読み込める最長のON時間もしくはOFF時間を“わざわざ”30msに制限していたためでした。

bto_advanced_USBIR_cmdはUSB_IR_Library_v4.1.0を機械的にポーティングしたものなので、その制限も受け継いでいたわけです。


bto_advanced_USBIR_cmdの方で制限を解くためには、

bto_advanced_USBIR_cmd.c:1196行目からの、
const uint ir_read_stop_on_time = 0x0008; // 読み込み停止 ON時間
const uint ir_read_stop_off_time = 0x0474; // 読み込み停止 OFF時間 30ms = 30ms / 38kHz = 1140 =0x474

// パラメータチェック
if (devh != NULL && IR_FREQ_MIN <= freq && freq <= IR_FREQ_MAX)
{
// データセット
outbuffer[0] = 0x31;
outbuffer[1] = (byte)((freq >> 8) & 0xFF);
outbuffer[2] = (byte)(freq & 0xFF);
outbuffer[3] = 1; // 読み込み停止フラグ 停止あり
outbuffer[4] = (byte)((ir_read_stop_on_time >> 8) & 0xFF); // 読み込み停止ON時間MSB
outbuffer[5] = (byte)(ir_read_stop_on_time & 0xFF); // 読み込み停止ON時間LSB
outbuffer[6] = (byte)((ir_read_stop_off_time >> 8) & 0xFF); // 読み込み停止OFF時間MSB
outbuffer[7] = (byte)(ir_read_stop_off_time & 0xFF); // 読み込み停止OFF時間LSB

を、

//const uint ir_read_stop_on_time = 0x0008; // 読み込み停止 ON時間
//const uint ir_read_stop_off_time = 0x0474; // 読み込み停止 OFF時間 30ms = 30ms / 38kHz = 1140 =0x474

// パラメータチェック
if (devh != NULL && IR_FREQ_MIN <= freq && freq <= IR_FREQ_MAX)
{
// データセット
outbuffer[0] = 0x31;
outbuffer[1] = (byte)((freq >> 8) & 0xFF);
outbuffer[2] = (byte)(freq & 0xFF);
outbuffer[3] = 0; // 読み込み停止フラグ 停止あり
outbuffer[4] = 0; // 読み込み停止ON時間MSB
outbuffer[5] = 0; // 読み込み停止ON時間LSB
outbuffer[6] = 0; // 読み込み停止OFF時間MSB

に修正すればOKです。
lircで実際の波形を送信しての受信テストもおこなっています。


近いうちに、正式な修正版をアップしたいと思います。

あと、先日 https://pastebin.com/TEeQt7p5https://pastebin.com/3F1w2Fue がデジタル的に同一と書きましたが、
正しくは、後半が微妙に違う命令でした。
イイね!の数:0
返信する
前の投稿 - 次の投稿 | 親投稿 - 子投稿なし | 投稿日時 2017-11-8 22:49
warp  <ROOKIE>   投稿数: 8
bto_advanced_USBIR_cmd.c に上記の通り変更を加えたところ、
要素数 1168 の信号がキャプチャでき、正常に動作する信号が
送信できることを確認いたしました。ご対応ありがとうございます!

取り急ぎご報告まで。
イイね!の数:0
返信する

このトピックに投稿する

題名
投稿本文