с ловлей багов в прошивках итд

Ну кому заработок позволяет купить готовое решение то взял готовое, а есть вот ещё люди до сих пор , сделай сам.

обрый день, Павел!
Складывается ощущение, что PRF64 не особо дружит с -F устройствами, ну либо имеющийся у меня SUF-1-300 не является таковым.
Во-первых, в режиме -F невоможно привязать SUF-1-300 из приложения. Но он совершенно без вопросов привязывается как обычный диммер.
Из чтения документации появилась мысль о том, что внутри шлюза есть фактически два устройства - MTRF64 и ethernet-обвязка с веб-интерфейсом. Я попробовал поработать со встроенным MTRF64 напрямую через NooliteONE - для этого я написал крошечную обвязку, которая дергала send.htm\receivе.htm, дописывала чексуммы и маркеры стоп\старта и кидала всё это в виртуальный ком-порт, к которому по замыслу должен был цепляться NooliteONE
В итоге устройство определилось как MTRF-64 v3 и NooliteONE запустился. И тут стали видны нюансы:

1) cmdReadState на всех каналах отдаёт ответ 2, хотя я вполне допускаю, что это возможно из-за того, что опрашиваются каналы -F, а устройство привязывается как обычный диммер.
TO MTRF: MODE:F-TX; COM:0; RES:0; CH:0; CMD:128; FTM:0; D0:0; D1:0; D2:0; D3:0; ID:0x00000000;
FROM MTRF: MODE=F-TX; ANSVER=2; TOGL=0; CH=0; CMD=128; FMT=0; D0=0; D1=0; D2=0; D3=0; ID=0x00000000;
TO MTRF: MODE:F-TX; COM:0; RES:0; CH:1; CMD:128; FTM:0; D0:0; D1:0; D2:0; D3:0; ID:0x00000000;
FROM MTRF: MODE=F-TX; ANSVER=2; TOGL=0; CH=1; CMD=128; FMT=0; D0=0; D1=0; D2=0; D3=0; ID=0x00000000;

2) попытка привязать устройство как -F заканчивается неудачей и выглядит так:
(включаю режим привязки на SUF-1-300)
TO MTRF: MODE:F-TX; COM:0; RES:0; CH:14; CMD:15; FTM:0; D0:0; D1:0; D2:0; D3:0; ID:0x00000000;
(2-3 секунды)
TO MTRF: MODE:F-TX; COM:4; RES:0; CH:14; CMD:15; FTM:0; D0:0; D1:0; D2:0; D3:0; ID:0x00000000;
SUF при этом не реагирует вообще никак.

То есть в целом процесс соответствует п. 5.1 документации MTRF-64, но SUF-1-300 не видит этого запроса.
При этом если делать всё руками через MODE:TX, то всё работает отлично:

Привязываем:
TO MTRF: MODE:TX; COM:0; RES:0; CH:15; CMD:15; FTM:0; D0:0; D1:0; D2:0; D3:0; ID:0x00000000;
FROM MTRF: MODE=TX; ANSVER=0; TOGL=0; CH=15; CMD=15; FMT=0; D0=0; D1=0; D2=0; D3=0; ID=0x00000000;

TO MTRF: MODE:TX; COM:0; RES:0; CH:15; CMD:2; FTM:0; D0:0; D1:0; D2:0; D3:0; ID:0x00000000;
FROM MTRF: MODE=TX; ANSVER=0; TOGL=0; CH=15; CMD=2; FMT=0; D0=0; D1=0; D2=0; D3=0; ID=0x00000000;
[лампочка зажглась]

TO MTRF: MODE:TX; COM:0; RES:0; CH:15; CMD:0; FTM:0; D0:0; D1:0; D2:0; D3:0; ID:0x00000000;
FROM MTRF: MODE=TX; ANSVER=0; TOGL=0; CH=15; CMD=0; FMT=0; D0=0; D1=0; D2=0; D3=0; ID=0x00000000;
[лампочка погасла]

это подходит под наколеночное? 😊

готовое решение, замечу. Выяснилось, что непропай в блоке контроллера.

Тех саппорт наверное выпал в белый осадок от такого расследования.

я просто до последнего думал, что это у меня руки кривые

и обратился в саппорт, когда совершено полностью был убежден в том, что туда имеет смысл писать 😊

А знакомое состояние, начинаем подготовливать базу под "это не я дурак, это у вас устройство кривое"

Прям тестирование по блекбоксу.

А не тыж код не разковыривал.

ну у меня была их железка которая работала по эзернет

и была диагностическая приблуда, которая работала с железками, которые работают по рс232

я отреверсил протокол и нашел способ отправлять и получать на ethernet-модуль те же команды, что и на рс232

дальше я написал софтинку, которая преобразует рс232-запросы в ethernet-запросы и обратно

и дальше я поставил её на виртуальный нулл-модемный кабель

в итоге диагностическая софтина увидела езернет модуль и смогла его отдиагностировать

самое смешное, что у них самих эта фича ещё в разработке, а тут на коленке на питоне за 2 часа.

Привет.