Сброс порта Rest API

Итак, POST и PATCH… PUT — это для создания НОВЫХ записей, как команда «add» в CLI… но порты Ethernet всегда существуют, поэтому нужен «PATCH», который в CLI соответствует «set». POST обычно повторяет саму команду CLI, включая «set» или «add» как часть URL (с .id в JSON-данных и остальными атрибутами, которые передаются в теле запроса / --data). PUT/PATCH используют .id в URL, поэтому его не нужно указывать в --json / --data.

Для всех вариантов нужно знать «.id» интерфейса (не просто имя). .id можно получить в CLI командой «/interface/ethernet/print show-id», где в первом столбце как раз нужный вам идентификатор для JSON — как для POST, так и для PUT.

Если у вашего PoE-порта .id *7 в выводе «print show-ids». (Кстати, можно сделать ДВА REST-запроса, если надо динамически получить .id, но это больше работы, если порт всегда один и тот же).

Я не тестировал, но должно работать примерно так:  
curl -X POST -k -u admin:password http://192.168.88.1/rest/interface/ethernet/set --json ‘{“poe-out”: “forced-on”; “.id”: “*7” }’

или…

curl -X PATCH -k -u admin:password http://192.168.88.1/rest/interface/ethernet/7* --json ‘{“poe-out”: “forced-on”}’

И вы можете перевести это на любую платформу домашней автоматизации — вместо curl, но «--json» делает несколько важных вещей, так что на большинстве платформ придется вручную задавать заголовок «Content-Type», который с curl включается автоматически:

–json (HTTP) — отправляет указанные JSON-данные в POST-запросе на HTTP-сервер.  
--json — это сокращение для передачи сразу трёх опций:  
–data [arg]
–header “Content-Type: application/json”  
–header “Accept: application/json”

Ещё лучше включить https (например, создать сертификат LE в /certificate/enable-ssl-certificate, затем включить «web-ssl» в /ip/services, используя этот сертификат). Но для теста из локальной сети подойдёт http на порту 80.