вот интересно - у вас выключатель изменяет своё состояние - статус и потом, в зависимости от его внутреннего состояния, вызывается соответствующий этому состоянию метод - turnOn/turnOff. Тогда, наверное, лучше назвать эти методы turnedOn/turnedOff?
Не логичнее с помощью методов turnOn/turnOff (включить/выключить) менять состояние/status, ведь так в реале происходит?
а если вдруг выключатель с обратной связью и может сам указать своё состояние? для него вы будете логику переписывать или класс отдельный создавать? при подходе, указанном выше, вы управляете выключателем методами, а реальное состояние прийдёт от выключателя по обратной связи. в случае использования выключателя без ос статус будет просто меняться в методе без слома всей логики. не?
Да, для простого устройства это не нужно, так как оно запускает метод turnOn/turnOff и соответственно устанавливается значение в свойстве status, но если настраивать меню управление, добавить выключатель и привязать к свойству status, то это в свою очередь при таком коде будет вкл\выкл устройство. Да, вы правы, может тогда сделать привязку метода setValue к свойство Value и оно будет запускать методы turnOn/turnOff?
а я вам уже где-то писал про настройку выключателя в меню для такой логики - 1 . привязать свойство статус реле к выключателю в режиме чтения. так положение выключателя будет всегда актуальным 2. привязать к выключателю метод switch, который при выполнении будет запускать turnOn/turnOff в зависимости от текущего статуса прибора. вообще-то, по большому счету, выбирать, чем управлять - статусом или методами - дело программиста. но тогда уж и методы надо называть соответственно, хотя бы) ну, должна же быть логика какая-то в названиях и аналогиях с реальным миром?
Да, вы писали это и благодаря вам я понял как это работает. Я удалил пункт про код в методе status. Он здесь лишний.
Если я не ошибаюсь - так не будет работать, если просто менять свойство (через админку или через sg();). А именно так и поступают выключатели в меню по дефолту. И из других методов проще вызывать sg, вместо методов turnon/turnoff, по этому команды в статье про бродлинк рекомендовал прописывать в statusUpdated.
Да, если менять свойство в status, то не будет включаться свет. По умолчанию простые устройства запускают методы turnOn/turnOff, а status служит индикатором того, что устройство включено или выключено. У меня есть устройства которые включаются\выключаются одной кнопкой, способ привязки к свойствам command_on\off не подходит, потому что если поставить свойство 1 оно включится, а если еще раз поставить 1 и просто обновить, то оно выключится, а статус будет показывать, что устройство включено. Тут что получается? Если в ПУ я нажму на включение лампы, то запустится метод turnOn, который в свою очередь установит в свойстве status 1 и сработает метод statusUpdated, который в свою очередь включит устройство через command_on. Возникает вопрос, не проще ли остановиться на методах turnOn/turnOff? Я поэтому и использую методы turnOn/turnOff.
Для устройств которые включаются 1 кнопкой в принципе не подходит тип ПУ выключатель. Для них есть тип "Кнопка". В вашем способе если устройство кто то включит не из МД - оно включится, и будет показывать, что оно выключено. Включите в МД - оно выключится. Полная рассинхронизация, устанете синхронизировать вручную.
Просто мне в одно время Сергей (создатель-разработчик МД) сказал что этот способ не совсем правильный, и объяснил логику, которую закладывал, что собственно я и передаю Вам, и всем кто прочитает статью. Как вам удобнее пользоваться - конечно же решаете вы сами. В метод statusUpdated можно вписать и 1 команду вместо 2. И будет оно работать как выключатель, но при этом вызывать только 1 команду. Вообще сейчас, когда есть функция brLinkCommand() в принципе не обязательно подвязываться к свойствам (command_on и command_off). И раньше кстати вообще в меню не было функции "только чтение", и ваш способ было бы не реализовать. Видимо и появилась она, чтобы подобное стало возможным.
Хорошо, что появилась такая замечательная функции "только чтение" ). Очень полезная функция. По поводу рассинхрона вы полностью правы, есть такое.
у меня свет управляется через ноолайт-пульты и напрямую, лишь сообщая серверу о действии. и неважно, кто включает свет в коридоре - мдм или человек выключателем, это планировалось изначально. никакой рассинхронизации нету(
а у вас выключатель noolite с обратной связью?
выключатели ноо только передатчики, сейчас стали делать исполнительные модули с ос. до этого ос не было. рассинхронизация в таком случае могла возникнуть, например, при отсутствии электричества или при перезагрузке сервера мдм. но у меня при рестарте мдм принудительно все реле выполняют метод рефреш, приводя свое состояние к запомненному
Please login to leave comments. Join us!