Вы не вошли. Пожалуйста, войдите или зарегистрируйтесь.
Не получается наладить гарантированное максимально быстрое выполнение команды.
Нужно отправлять команду в цикле до получения квитанции. от трекера Можно ли это реализовать?
Сейчас если выбрать TCP, то есть вероятность потери команды. Или вообще невозможность ее отправки, если трекер не онлайн.
Если выбрать Virtual, то все вроде хорошо, но команда идет только и сразу после получения сообщения от трекера. Нужно асинхронно.
Не получается наладить гарантированное максимально быстрое выполнение команды.
Нужно отправлять команду в цикле до получения квитанции. от трекера Можно ли это реализовать?Сейчас если выбрать TCP, то есть вероятность потери команды. Или вообще невозможность ее отправки, если трекер не онлайн.
Если выбрать Virtual, то все вроде хорошо, но команда идет только и сразу после получения сообщения от трекера. Нужно асинхронно.
Вы описали абсолютно корректную и ожидаемую работу команд.
Пожалуйста, поясните, что вы подразумеваете под "асинхронной" отправкой команд, а также как вы предполагаете отправку через TCP, если трекер не на связи.
Еще раз попробую донести проблему.
Если выбрать Virtual, а трекер шлет данные через 5 минут, то команда уйдет на трекер сразу после получения данных, то есть, возможно придется ждать 5 минут. Команда привязана к кадру, а не улетает сразу. Именно это я имел в виду под словом асинхронно.
Если выбрать TCP, то команда уходит сразу, это гуд. Но, если трекер не на связи, то команду вообще нельзя отправить. Опять засада.
Пользователю вообще нет разницы TCP там или чтото еще. Отправил команду и получил ответ, что команда выполнена.
Вот как раз этого мы и не можем получить.
И проблема еще в том, что нет обратной связи. Вернее, она есть, но неполноценная. Нет возможности автоматически досылать команду, если она не выполнена.
Стоит пояснить, что команда с типом Virtual по сути является той же командой с типом TCP, но с добавленной очередью. То есть она тоже отправится, когда объект выйдет на связь, но зато вам не придётся ловить этот момент вручную, чтобы отправлять команду, как в случае с TCP.
Предположу, что вы можете изменить конфигурацию устройства, чтобы оно постоянно было на связи, и тогда команды будут отправлять быстрее. Либо вы можете попробовать отправлять команды через SMS, так как в таком случае состояние оффлайн не должно повлиять на отправку (только если оффлайн не связан с нахождение ТС вне зоны доступа сети).
rse72 TCP команда -- это команда, которая может быть отправлена во время установленного TCP соединения.
Т.е. если прибор не на связи, сервер не может отправить TCP команду.
Инициатором соединения всегда является трекер. Сервер не может установить TCP соединение, только трекер (т.е. тут односторонняя связь). Сервер не может отправить TCP посылку, как смс по номеру телефона, т.к. не существует такого постоянного уникального "адреса трекера в интернете" (как, например, номер телефона в случае GSM адресации), чтобы установить соединение.
Таким образом, если вы выбираете тип команды TCP, это значит что выполнить её можно только тогда, когда трекер держит соединение и прошло не более 300 секунд с момента последней посылки (это либо сообщение с данными, либо какой то heartbeat пакет).
Если TCP соединение доступно, то сервер выполнит команду сразу же.
Виртуальный тип команды описан вами верно. Физически это таже TCP команда, но выполняется она не сразу, а только со следующей посылкой от трекера в момент получения этого сообщения. Вероятность доставки виртуальной команды выше, чем TCP, потому что сервер доподлинно на 100% не может понять, установлено сейчас TCP соединение или нет. Потому что если прибор не выслал спец. маркер о разрыве соединения возможна такая ситуация, что индикатор активного TCP соединения горит зеленым, но на самом деле команда не будет доставлена. В случае virtual команда отправляется в момент получения данных (следующего сообщения) и вероятность того что соединение установлено значительно выше.
По поводу "квитанции". Далеко не все трекеры присылают ответ на команду. Т.е. доставка команды это не значит её успешное выполнение. Кроме того, чтобы серверу понять, что команда выполнена безуспешно, надо чтобы не только трекер прислал ответ, но и сервер понял этот ответ. Но обычно ответ на команды от трекеров -- это текст, причем текст, генерируемый произвольно на выполнение команд (и ответ этот может разниться в зависимости от типа команды). Т.е. в протоколах трекеров не всегда прописано четкое описание посимвольного ответа на все команды. Разбирать этот ответ, чтобы ответ был понятен серверу в автоматическом режиме, очень сложно.
Я прекрасно понимаю, что у вас TCP и Virtual. Читал мануал + проверил все на практике.
Поэтому и не спрашиваю, как это работает, а как сделать из этого чтото нужное конечному пользователю.
Похоже, что никак.
Ну и про квитанцию еще добавлю. Многие трекеры шлют состояние выхода в явном виде. Т.е. в качестве квитанции можно было бы использовать состояние датчика на выбор.
Т. о. можно было бы просто отправлять команду при наличии соединения с трекером каждые N секунд до появления нужного состояния на сенсоре S.
Ничего сложного, вроде.
Не получается наладить гарантированное максимально быстрое выполнение команды.
Нужно отправлять команду в цикле до получения квитанции. от трекера Можно ли это реализовать?Сейчас если выбрать TCP, то есть вероятность потери команды. Или вообще невозможность ее отправки, если трекер не онлайн.
Если выбрать Virtual, то все вроде хорошо, но команда идет только и сразу после получения сообщения от трекера. Нужно асинхронно.
Если протокол, по которому Вы работаете с трекером интегрирован во flespi, то команды работают там именно так. Если устройство живое, команда улетает мгновенно, причем там где возможно анализируется ответ трекера. Если сейчас соединения нет, то команда улетит как только трекер подключится и идентифицируется.
Вот по этой инструкции можно прямо со стандартных инструментов Wialon (задания, уведомления, интерфейс) отправлять команды на устройства работающие через flespi.
