بيانات الاعتماد لا تطلب عنوان SimpleX، بل تطلب مكان الوصول إلى واجهة سطر الأوامر (CLI)، وهذا هو الجزء المفقود على خادمك. يتصل العقدة بـ simplex-chat عبر WebSocket، لذا يجب بدء واجهة سطر الأوامر كخادم وليس كدردشة تفاعلية تكتب فيها:
simplex-chat -p 5225
بعد ذلك في بيانات اعتماد SimpleXity، عيّن Host إلى localhost، وPort إلى 5225، واترك Bot Address فارغاً، حيث ستنشئ العقدة واحداً عند أول اتصال. حافظ على هذه العملية قيد التشغيل تحت systemd أو tmux، لأن المشغّل ينطلق فقط أثناء تشغيلها، ولاحظ أنها تستخدم نفس الملف الشخصي الذي اختبرته، لذا تنقل جهات اتصالك الحالية.
للإرسال، تريد عقدة Action معرّف جهة الاتصال الرقمي بدلاً من عنوان SimpleX. أسهل طريقة للحصول عليه هي إرسال رسالة إلى الروبوت من هاتفك مرة واحدة، واتركه ينطلق المشغّل، واقرأ contactId من إخراجه، ثم استخدمه في عقدة الإرسال.
مرحباً @gchilloux أهلاً وسهلاً!
هذا هو الإعداد الصحيح. الجزء الذي يتركه مفتوحاً هو العنوان نفسه: إنه رابط جهة الاتصال SimpleX للبوت ويوجد في ملف تعريف CLI، وليس في n8n. اكتب /show_address في CLI للحصول عليه، أو اكتب /address مرة واحدة إذا كان يقول إنه ليس لديك أي واحد، وشارك هذا الرابط مع أي هاتف يجب أن يصل إلى البوت. المشغل ينشئ عنواناً عند التفعيل عندما لا يكون للملف الشخصي أي واحد، لكنه يكتبه فقط في سجل n8n، ويفعّل القبول التلقائي بحيث تتصل جهات الاتصال الجديدة دون استخدام /accept يدوي. هاتفك الخاص هو بالفعل جهة اتصال لهذا الملف الشخصي من اختبار CLI الخاص بك، لذلك لا يحتاج إلى رابط، رسالة واحدة منه تفعّل المشغل برقم معرّفه.
هناك نقطتان من كود المشغل. ليس لديه دالة مشغل يدوية، فقط trigger() طويل الأجل، لذا ستدور خطوة التنفيذ إلى الأبد ولن تعرض شيئاً. يعمل فقط عندما يكون سير العمل نشطاً، وتتحقق من قائمة التنفيذات بدلاً من لوحة العمل. ثم المحتمل أن يكون هناك عائق: عقدة الإرسال تفتح عميل ChatClient خاص بها لنفس WebSocket ولا تغلقه أبداً، لذا يتنافس مشغل نشط وعقدة إرسال على مقبس CLI الواحد، وعندما ينقطع حلقة المشغل، يذهب الخطأ فقط إلى console.error.
فعّل سير العمل وتحقق من سجلات n8n الخاصة بك عن Connecting to SimpleXity at localhost:5225. عدم وجود سطر يعني أن المشغل لم يبدأ أبداً، وError in message processing loop يعني أنه بدأ وانقطع.
اختبر المشغل وحده، في سير عمل بدون عقدة إرسال.
أرسل رسالة مباشرة من هاتفك، الرسائل الجماعية يتم تخطيها بالتصميم.
أعد تشغيل CLI بين الاختبارات حتى لا يبقى أي مقبس نصف ميت مرتبطاً.
إذا ظهر سطر الاتصال لكن رسالة مباشرة لم تنتج أي تنفيذ، فهذا يستحق مشكلة على المستودع مع تلك السطور من السجل.
بناءً على سؤالك، تقول السجلات العامة أنه لم يفعلها أحد. المشكلة 2 في المستودع هي شخص يسأل بالضبط عن كيفية استقبال الرسائل، مفتوحة وبدون إجابة منذ ديسمبر، ولم تكن هناك إصدارة جديدة منذ 0.2.0 في أغسطس 2025.
لا يوجد إعادة اتصال ولا إنهاء اتصال في مصدر الحزمة، لذا لا شيء تقوم بتكوينه من جانب n8n يغيره. افتح المشكلة مع سطور السجل الخاصة بك واعتبر المشغل محظوراً في المتابع.
للرسائل الواردة في الوقت الراهن، اعكس الأمر. قم بتشغيل نص برمجي صغير كوحدة systemd يحتفظ بـ WebSocket بـ CLI ويرسل كل رسالة إلى عقدة Webhook في n8n. ثم تجلس منطق إعادة الاتصال في شيء تتحكم فيه، وعقدة Webhook هي أموثق مشغل لديه n8n.
هذا منطقي. إذا كان المُشغِّل نفسه لا يتعامل مع إعادة الاتصال أو الحفاظ على استقرار اتصال websocket، فإن نقل معالجة الرسائل الواردة إلى خدمة خارجية صغيرة + webhook من n8n يبدو أنه الحل العملي الأكثر فعالية في الوقت الحالي.
أواجه صعوبة في اختبار Telegram/WhatsApp/Discord على n8n المحلي عبر Docker – عناوين Webhook تجعلني مجنوناً!