Неисправность knx модуля мы исключили. Пробуем сброс контроллера до заводского?
Какие-то чудеса. Взял и поменял KNX-модули местами. На том объекте, где сразу “включилось” (пусть для определенности будет “объект 2”) - с проблемным модулем тоже все завелось - данные вижу.
Заведомо исправный модуль воткнул в WB на проблемном объекте (“объект1”). Ситуация повторилась - тишина, ничего нет. Пошел дальше - снова разобрал WB и переставил модуль из 2 слота в 1 слот. Все параметры knxd установил по умолчанию. Переконфигурировал “железо” и внезапно увидел данные:
i:4/1/4 g:15/0/1 GroupValueWrite 0x0c 0xfd
Если я правильно читаю это, то тут телеграмма от устройства 4.1.4 в группу 15/0/1 - но тут уже несоответствие: физический адрес устройства правильный - это термостат, но вот вещает он в группу 31/0/1
Т.е. возможно, это какой-то “глюк” в конфигурации, хотя WB пришел с уже установленным и сконфигурированным модулем.
Это ситуация на “объекте1”
Сейчас смотрю, схожая ситуация и на “объекте2”:
i:5/1/2 g:12/3/1 GroupValueWrite 0x0c 0x7a - вот телеграмма…
Опять адрес правильный: 5.1.2 (датчик движения/освещенности/температуры), а вот групповой адрес должен быть 28/3/1
Похоже, что, модуль неправильно отрабатывает “старшие” групповые адреса.
И теперь вопрос, как мне все-таки вытащить данные?
Проекты KNX мне менять нельзя (там все уже отлажено и конфигурации раскатаны по объектам)
И еще, у меня эти две WB хотя и на разных объектах (физически), но находятся в одной сети. И я вижу сообщения шины из с объекта1 на WB объекта2 (и наоборот) - смотрю топики “/devices/knx/controls/data”. Похоже, в широковещательном режиме работают knxd и “всем, кто готов слушать, рассказывают”. Как отработать эту ситуацию? Оба knxd настроены праметрами по умолчанию.
Для разбора использую скрипт, который нашел тут же (в соседней ветке по KNX)
(function() {
//From settings /etc/wb-knxd-config.conf
//"Staic" part address, NUMBER
var LocalADDR0 = 1;
var LocalADDR1 = 1;
//"Dynamic" range address, number
var LocalADDR2=92
var LocalADDR2count=8
log.debug("Local address", LocalADDR0+"/"+LocalADDR0+"/"+LocalADDR2+":"+(LocalADDR2+LocalADDR2count));
var knx_vdev_obj = {
title: "KNX4 Group Addresses",
cells: {
"15-0-0": {
type: "temperature",
scale: 0.1,
value: 0,
readonly: true
},
"31-0-1": {
type: "temperature",
scale: 0.1,
value: 0,
readonly: true
},
"31-0-2": {
type: "temperature",
scale: 0.1,
value: 0,
readonly: true
},
"31-1-0": {
type: "temperature",
scale: 0.1,
value: 0,
readonly: true
},
"31-1-1": {
type: "temperature",
scale: 0.1,
value: 0,
readonly: true
},
"31-1-2": {
type: "temperature",
scale: 0.1,
value: 0,
readonly: true
}
}
};
var vdev_when_changed = [];
var vdev_devid = "knx4_group_addrs";
for (var control_id in knx_vdev_obj.cells) {
if (knx_vdev_obj.cells.hasOwnProperty(control_id)) {
vdev_when_changed.push("knx4_group_addrs/" + control_id);
}
}
defineVirtualDevice(vdev_devid, knx_vdev_obj);
defineRule("knx_vdev_feedback", {
whenChanged: vdev_when_changed,
then: function(newValue, devName, cellName) {
log.info("vdev_when_changed", newValue, devName, cellName)
var group_address = cellName.split("-").join("/");
var value = +newValue;
var write_str = "";
if (knx_vdev_obj.cells[cellName].knx_type == "wide") {
while (value > 0) {
var rem = value % 256;
value = Math.floor(value / 256);
write_str = rem + " " + write_str;
}
write_str = "0 " + write_str;
} else {
write_str = "" + value;
}
if (write_str) {
dev["knx/data"] = "g:{} GroupValueWrite {}".format(group_address, write_str);
}
}
});
defineRule("knx_vdev_incoming", {
whenChanged: "knx/data",
then: function(newValue, devName, cellName) {
var arr = newValue.split(/\s/);
var sourceAddr = arr[0].split(/i\:|\,/);
sourceAddr=sourceAddr[1].split("/") //Разбиваем адрес источника (отправителя) на элементы.
var groupAddr = arr[1].split(/g\:|\,/);
var arr1 = newValue.split(/GroupValueWrite/);
var value = arr1[1];
log.debug("** sourceAddr.length", sourceAddr.length, "sourceAddr", sourceAddr )
//Если адрес источника нулевой или совпадает с адресом клиента
if ((sourceAddr[0] == LocalADDR0)&(sourceAddr[1] == LocalADDR1) & (sourceAddr[2] >= LocalADDR2) & (sourceAddr[2] <= (LocalADDR2+LocalADDR2count)) ) { // skip local echo
log.debug("Local echo from", sourceAddr[1], "scipped")
return;
}
dev[vdev_devid][groupAddr[1].split("/").join("-")] = !!parseInt(value, 16);
}
});
})()
function knxConvertToFloat16(value) {
var sign = 0;
var exp = 0;
if (value < 0) {
sign = 1;
}
var mant = Math.floor(value * 100);
while ((mant < -2048) || (mant > 2047)) {
mant = mant >> 1;
exp += 1
}
var data = (sign << 15) | (exp << 11) | (mant & 0x07ff);
return data;
};
function convertfromKnx(value) {
var byte1 = "0x" + value[3] + value[4];
var byte2 = "0x" + value[8] + value[9];
var data = parseInt(byte1, 16) * 256 + parseInt(byte2, 16);
var sign = data >> 15;
var exponent = (data >> 11) & 0x0f;
var mantisse = data & 0x7ff;
if (sign) {
mantisse = -2048 + mantisse;
}
output = (mantisse * (Math.pow(2, exponent)) / 100);
return output;
};
групповые адреса пробовал записывать как они есть на самом деле (31-0-1 и т.п.) и так, как вижу их в телеграмме (15-0-0) - результат одинаковый. В значениях стоят нули и не меняются.
Модуль KNX это просто приемопередатчик из шины в UART, обработку сообщений осуществляет KNXd. Скорее всего глюк программный и возможно только вы на него попали из за особенностей адресации проекта.
а вот это место правильно отрабатывает в скрипте?
Проект KNX нормальный, ETS его сделала, проверки все проходят, оборудование все работает.
В любом случае, этот косяк надо исправлять.
Кабы я знал. Скрипт не я писал. Если честно, вообще не очень понимаю, как оно должно работать.
Нужен ответ от представителей WB, скрипт на JS, возможно там идет некорректное вычисление старшего адреса.
Точно что то в математике преобразования. Смотри, у тебя в проекте используются старшие адреса 31 и 28, в WB показывается 15 и 12 соответственно. Сделав небольшие вычисления получается что отбрасывается 16 при преобразовании, притом очень ровненько.
Вообще рекомендую перейти на тестинг и использовать новый мост knx-mqtt. Да, преобразования в старых скриптах могут не очень корректно отрабатывать, точнее там надо явно указывать тип для каждого группового адреса.
Но основное тут - то что knxd не обрабатывает адреса в шине. И то что модуль цел - было понятно уже по тому что он, модуль принимает в minicom телеграммы.
А может скрипт подправить?
Так не сомневаюсь
В продакшен проекте на тестинг - ну такое.
Знать бы как? Я ж попробовал подсовывать туда групповые адреса, как они видны со стороны WB, но это не помогло - все равно “нули”.
тут нужен программер на JS.
Независимо от скрипта - должны быть данные из шины в MQTT. если их нет - то копать надо knxd.
Попробую воспроизвести с такой же адресацией.
спасибо, ждем результатов.
Сейчас какие-то (ошибочные) данные есть.
Но скрипт-то все равно не отрабатывает. Ни по правильным адресам, ни по тем, что видны в MQTT. Или (возможно) нужна какая-то более подробная инструкция, что со скриптом делать, чтобы он данные все-таки разбирал.
Спасибо, очень ждем.
Вы (возможно) неправильно понимаете архитектуру. Это не “ошибочные” данные. Это просто топики виртальных устройств. Все взаимодействие с шиной KNX идет через один топик /devices/knx/controls/data/
Поэтому предлагаю отключить скрипт и добиться того чтобы из шины все же попадали данные в knxd. Сейчас пробую с адресами 4.1.x
И, кстати - тоже попробуйте поменять один из групповых на какой-нибудь 1.1.
4.1.x или 4/1/x ?
Данные в топик у меня попадают (я ж скриншоты привожу). Но они в этом топике - ошибочные. Групповые адреса (“старшие” - 31/0/1, 28/1/1 к примеру) - ИСКАЖАЮТСЯ.
Физические адреса (4.1.1 и т.п. и 5.1.2 и т.п.) - идут ВЕРНЫЕ.
Попробуйте повторить мою адресацию (не только физ.адреса устройств: еще раз - с ними проблем НЕТ, но и групповые адреса - вот тут и ЕСТЬ проблема).
Объект удаленный, непросто это.
P.S. еще хорошо бы придерживаться нотации KNX в написании физических адресов (х.х.х - через точки), в написании групповых адресов (y/y/y - через слеши). Сейчас при работе с WB вообще с адресами полные непонятки: встречаются записи через точки (в настойках knxd, встречаются записи через дефисы (в скриптах), встречаются записи через слеши (в mqtt - и там через слеши идут и физические адреса, и групповые)… поэтому могут быть еще и дополнительные ошибки просто из-за непонимания, с какими адресами работаем.
Поддержу, думаю стоит проработать пограничный вариант 14/x/x 15/x/x 16/x/x 17/x/x, думаю на 17ти как раз и вылезет проблема.
1 лайк
Итак, для начала определил адрес устройства 4.1.2
и групповой для канала - 28/3/1
Подписываюсь, смотрю:
mosquitto_sub -v -t /devices/knx/#
/devices/knx/meta {"driver":"wb-mqtt-knx"}
/devices/knx/meta/name wb-knx
/devices/knx/meta/driver wb-mqtt-knx
/devices/knx/controls/data i:5/1/2 g:12/3/1 GroupValueWrite 0x00
/devices/knx/controls/data/meta {"order":0,"readonly":false,"type":"text"}
/devices/knx/controls/data/meta/order 0
/devices/knx/controls/data/meta/readonly 0
/devices/knx/controls/data/meta/type text
/devices/knx/controls/data i:5/1/2 g:12/3/1 GroupValueWrite 0x01
/devices/knx/controls/data i:5/1/2 g:12/3/1 GroupValueWrite 0x00
/devices/knx/controls/data i:5/1/2 g:12/3/1 GroupValueWrite 0x01
/devices/knx/controls/data i:5/1/2 g:12/3/1 GroupValueWrite 0x00
/devices/knx/controls/data i:5/1/2 g:12/3/1 GroupValueWrite 0x01
/devices/knx/controls/data i:5/1/2 g:12/3/1 GroupValueWrite 0x00
Три раза нажимал кнопку - телеграммы есть.
Проверю сейчас и с 14…17