#defineFEATURE_EEPROM_ENABLE, наверняка, активирован. Настройки при первом запуске сохраняются в EEPROM, потом могут модифицироваться по сети. Новые настройки перезаписываются на место старых при процедуре Factory Reset, например (описана в документации, нужен один проводок).
в первую очередь хочу сказать Вам спасибо за Zabbuino, это, пожалуй, лучшее, что я видел для ардуино за всё время. Надеюсь, вы не бросите этот проект.
У меня вопрос про DS18B20 и Zabbix 4.x, они почему-то не хотят дружить, а этот датчик один из самых популярных и востребованных. Причем если делать по Вашему совету айтем с ключем DS18x20.Temperature[2,9] то первый в цепочке датчик действительно отвечает корректно, но если добавить еще и адрес датчика, то получаем -136. Ключ ow.scan[2] тоже ничего не выдает (точее ошибка Warning: Message from 192.168.1.10 is longer than expected 19 bytes. Message ignored. Из консоли результат аналогичный.
Уверен, вы знаете, как это исправить :) Перейти обратно на Zabbix 3.4 не вариант.
Очень прошу Вашей помощи, без Вас нам не справиться!
C ow.scan[] проблема есть, но с датчиками (адресными и безадресными) явно не наблюдается.
C:\zabbix\v4>zabbix_get.exe -s 172.16.100.227 -k "DS18x20.Temperature[2,9,0x28FFE47861160410]"
24.5
C:\zabbix\v4>zabbix_get.exe -s 172.16.100.227 -k "ow.scan[2]"
zabbix_get.exe [1744]: Warning: Message from 172.16.100.227 is longer than expected 19 bytes. Message ignored.
zabbix_get.exe [1744]: Get value error:
zabbix_get.exe [1744]: Check access restrictions in Zabbix agent configuration
C:\zabbix\v4>zabbix_get.exe -V
zabbix_get (Zabbix) 4.2.4
Revision 059af02 26 June 2019, compilation time: Jun 27 2019 12:29:03
Copyright (C) 2019 Zabbix SIA
License GPLv2+: GNU GPL version 2 or later <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it according to
the license. There is NO WARRANTY, to the extent permitted by law.
sadman41,
Спасибо большое за ответ, Вы мой спаситель, а я идиот )))
прописывал адреса датчиков в формате Linux, а Arduino ждет свой формат...
если в Linux (RPi) датчик имеет, например, адрес:
28-021391771f30
то в Ардуино это:
0x28, 0x30, 0x1F, 0x77, 0x91, 0x13, 0x02, 0x48 или 0x28301F7791130248
как считаются последние две цифры чексуммы я не знаю, но по виду это адрес наоборот и чексумма.
и Zabbuino, естественно, ждет второй вариант адреса... возможно кому-то это поможет, надеюсь я не один такой, кто определяет адреса датчиков с помощью Raspberry Pi )))))
Отсюда у меня к Вам второй вопрос, можно ли как-то починить OW.SCAN или в 4.х он не будет работать никогда по каким-то объективным и не зависящим от Вас причинам? Если бы он работал, этой досадной ошибки возможно можно было бы избежать.
прописывал адреса датчиков в формате Linux, а Arduino ждет свой формат...
если в Linux (RPi) датчик имеет, например, адрес: 28-021391771f30
то в Ардуино это: 0x28, 0x30, 0x1F, 0x77, 0x91, 0x13, 0x02, 0x48 или 0x28301F7791130248
как считаются последние две цифры чексуммы я не знаю, но по виду это адрес наоборот и чексумма.
У Ардуино никакого "своего формата" для устройств 1-wire нет. Применяется стандарт (см. в статье): У каждого устройства 1-Wire есть 64-разрядный идентификатор (ID). Он состоит из 8-разрядного кода семейства, который идентифицирует тип устройства и поддерживаемые им функции, 48-разрядного серийного номера и 8-битного поля кода циклического избыточного контроля (CRC-8).
То, что библиотеки в Linux занимаются самодеятельностью (если это так) - беда, конечно.
sharuspb пишет:
Отсюда у меня к Вам второй вопрос, можно ли как-то починить OW.SCAN или в 4.х он не будет работать никогда по каким-то объективным и не зависящим от Вас причинам?
Да, я подфиксил. Забирать там же, на гитхабе. Но, если Zabbix SIA продолжит заниматься развитием IoT-направления в том же стиле, что и сейчас - прошивки будут влезать только в Мегу или вообще никуда не будут влезать.
Ура! Всё заработало! Сам поправил по образу и подобию нового корректного service.cpp из мастер-ветки гитхаба и теперь ow.scan и в zabbuino 1.3.1 работает ) Спасибо!!!
_stream.print('\n');
А насчет адресов датчиков DS18B20. Вот как их видит Raspberry Pi:
А насчет адресов датчиков DS18B20. Вот как их видит Raspberry Pi:
Ничего с этим не могу поделать.
И, если бы Вы заглянули в руководство, на которое я потратил изрядно времени, то в описании ключа могли бы увидеть пример запроса (вместе с форматом записи DS18x20 ID).
Понятно, что на формат RPi Вы не влияете. Ваше, отличное, кстати, руководство я читал и даже очень внимательно, но согласитесь,
0x28021391771F30 и 0x28301F7791130248
выглядят весьма похоже, хотя это два разных формата одного датчика... вот и не заметил подвох, который выявился только благодаря вашей помощи, за что Вам еще раз большое спасибо!
Пользуясь случаем спрошу, какие планы у Вас по дальнейшему развитию платформы? Когда планируете перенос изменений эксперементальной ветки в основную?
но согласитесь, 0x28021391771F30 и 0x28301F7791130248
выглядят весьма похоже, хотя это два разных формата одного датчика...
Один какой-то коцанный. Ну, да это вопрос к пейсателям драйвера Linux. За всеми не уследишь.
sharuspb пишет:
Пользуясь случаем спрошу, какие планы у Вас по дальнейшему развитию платформы? Когда планируете перенос изменений эксперементальной ветки в основную?
Встречный вопрос - что Вы ожидаете увидеть при переносе экспериментального бранча в мастер? Радикально ничего не изменится, в принципе. Сократить размер прошивки, в чём была основная идея следующего релиза, не удалось, так что изменения вовсе могут быть незаметны для простого пользователя.
Планы же, в принципе, есть. Только нет заинтересованных в них лиц.
Встречный вопрос - что Вы ожидаете увидеть при переносе экспериментального бранча в мастер? Радикально ничего не изменится, в принципе. Сократить размер прошивки, в чём была основная идея следующего релиза, не удалось, так что изменения вовсе могут быть незаметны для простого пользователя.
Планы же, в принципе, есть. Только нет заинтересованных в них лиц.
Судя по логу на гитхабе, в 1.3.1 довольно много изменений, по сути это две очень разных версии по коду. У меня стоит 1.3.1 и после того, как пришлось самому переносить в неё изменения для работы ow.scan подумалось, что было бы лучше иметь одну ветку, раз в экспериментальной сейчас нет ежедневных/еженедельных билдов, она вполне заслуживает стать основной, уступив место 1.3.2 для будущих идей ;)
И не соглашусь с Вами, что нет заинтересованных лиц, возможно вы судите по низкой активности на этом форуме? Вероятно, что Ваш продукт уже настолько хорош, что многие его успешно используют и у них не возникает необходимости задавать вопросы. К тому же, мониторинг Zabbix штука сама по себе очень специфичная, и его основые пользователи не совсем из мира Arduino, а больше из среды сетевого айти и резонанс проекта был бы выше именно на ресурсах данного направления (habr, форумы zabbix, reddit и т.д.). Я сам далеко не сразу нашел этот форум, где мы сейчас общаемся, на гитхабе нет четкого указания и ссылки, где можно задать вопрос автору (кроме почты и Я.Мани, других контактов я не нашел). Кстати, Я.Мани есть далеко не у всех... пэйпал и/или карточка имели бы больший успех, кто-то на хабре это даже тестил )
Извините, что немного поумничал, но я вижу, что вы настроены писсиместично, и боюсь, что вы забросите этот прекрасный проект. Я, к сожалению, не программист, а так бы с удовольствием подключился бы к разработке. В любом случае спасибо вам за этот труд, вы сделали больше всех для связи zabbix с физическим миром!
Судя по логу на гитхабе, в 1.3.1 довольно много изменений, по сути это две очень разных версии по коду. У меня стоит 1.3.1 и после того, как пришлось самому переносить в неё изменения для работы ow.scan подумалось, что было бы лучше иметь одну ветку, раз в экспериментальной сейчас нет ежедневных/еженедельных билдов, она вполне заслуживает стать основной, уступив место 1.3.2 для будущих идей ;)
Очень разных версий у меня очень давно не было. В сущности - это один и тот же скелет, на который навешиваются функции, взаимодействующие с новыми сенсорами. То, что меняется внутри - это мои личные тараканы и попытки как-то уменьшить объём прошивки. Пользователь с этим не сталкивается.
В логе я упустил, конечно, но де-факто всё, что датируется 30 Apr 2019 и позже - v1.4, в которую перетянуты фичи из нового релиза драйвера Wiznet, произведена попытка как-то сократить количество debug-сообщений (но обычно они отключены и никак не увеличивают объём прошивки) и ведутся попытки как-то сэкономить на спичках в функциях, взаимодействующих с сенсорами. Где получается - делаю автовыбор диапазона измерения (например для BH1750 и тэдэ).
sharuspb пишет:
И не соглашусь с Вами, что нет заинтересованных лиц, возможно вы судите по низкой активности на этом форуме?
Не только. Гитхаб даёт статистику по бэклинкам и я вижу откуда приходят люди и в каких количествах. Странно, что Вы не нашли тему на форуме Zabbix - по запросам типа "Arduino Zabbix" в яндексе она не первая, но в тройке лидеров.
То, что продукт специфический - верно и с этим нельзя не согласиться. Мало кому из ардуинщиков удастся разобраться в Zabbix, а Zabbix-одов - в ардуине.
sharuspb пишет:
Кстати, Я.Мани есть далеко не у всех... пэйпал и/или карточка имели бы больший успех, кто-то на хабре это даже тестил )
Тестить - это одно, а реальность - другое. Сначала у меня висел пэйпал, но когда он начал меня заваливать каким-то безумными требованиями предоставить удостоверяющие документы - я просто закрыл свой аккаунт у них.
За всё время, пока на гитхабе висели donate buttons (года три), я получил через них 0 единиц. В любой валюте, которая Вам более по душе. Ну, и были два человека, которые предоставили сенсоры (MH-Z19B и PZEM-004) для интеграции. Все остальные датчики, поддержка и развитие прожекта - за свой счёт. Т.е. работа в реальный минус.
Такова действительность. Пессимизм или оптимизм не имеют с ней ничего общего. Посему - никаких еженедельных или, не дай бог, ежедневных билдов. Удаётся что-то новое прикупить из железок - интегрирую.
Вы упомянули датчик PZEM-004T, у китайцев сейчас продается версия 3.0 с измененным (как они пишут) протоколом связи - теперь это стандартный Modbus-RTU. Ардуино его вроде бы поддерживает. В текщей реализации поддержки этого датчика в Zabbuino 1.3 аппаратная версия датчика с Modbus-RTU будет работать?
Очень жаль, ведь Modbus используется во всей современной автоматизации, позволяет использовать RS-485 и т.д. Есть ли шанс, что вы всё же прикрутите его к своему проекту? :)
Вопрос всегда в мотивации )) Например, безвоздмездное предоставление вам этого датчика с Modbus-RTU интерфейсом могло бы сподвигнуть вас на оперативную разработку решения? ;)
Нет, мне его в хозяйстве некуда пристроить. На интеграцию надо 2-3 рабочих дня (в лучшем случае) потратить. Ненужный датчик за 800р этого явно не покрывает.
Тогда сами напишите, о какой достаточной мотивации идет речь, чтобы нам тут не гадать... устроим кикстартер ))
Ну, смотрите: вы всегда можете точно определить время выполнения работы, которая не является основной по профилю? Наверняка - нет.
Читали ли Вы что-то про модбас? Представляете его полную функциональность (форматы отдаваемых чисел, порядок следования байт в регистре и т.д. и т.п.), которая скажется на трудоёмкости реализации и добавочном размере прошивки? Почитайте, подумайте - имеет ли смысл полностью его вкрячивать? Наверняка - нет.
Т.е. на сложность определения затраченного времени накладывается ещё не проработанная концепция "усечения осетра". А теперь решите уравнение (X+Y)*Z, где известно только Z (судя по разделу "ищу исполнителя" - оно составляет 3т.р. в день на данный момент).
И не подумайте, что я что-то выторговываю там или глазки строю. С библиотечкой modbusRTU задача действительно решается на раз-два. Ну, и где-то 30-40% ресурсов ATMega328 будет израсходовано. Это непозволительно много, так как постоянно поджимает сетевая часть (в том числе благодаря изменениям, которые вносит Zabbix SIA в свою протокольную часть). Сейчас минимальная часть (ядро) системы в Progmem Space - ~19кб. Это с W5100. С ENC28J60 - ~24кб. Т.е. около 60-75% ресурса популярного и дешёвого Ардуино-МК. Модбас, всунутый с библиотекой, - 90-115% ресурса. Неприемлемо. Желательно по модбасу уложиться в 10-20% чтобы осталось ещё хоть на какой-то градусник или на будущее.
Вдавливание же модуля с минимально достаточным функционалом в 10% ресурсов МК - это процесс с реально непрогнозируемым финалом.
Тогда сами напишите, о какой достаточной мотивации идет речь, чтобы нам тут не гадать... устроим кикстартер ))
У меня появилась одно соображение насчёт того, как на основе взаимовыгодного сотрудничества вкрячить Modbus в прошивку. Если интересно - адрес email на github-e.
Добрый день, есть задача получить в zabbix сигнал в случае пропадания питания на устройстве. Подскажите какое оборудование будет оптимально использовать для этой задачи на текущий момент, для вашей прошивки. В первом посте у вас указано использование Peacefair PZEM-004, но его нет на гитхабе в списке поддерживаемых, плюс сейчас появились новые версии. Спасибо.
Самое наипростейшее, что собирается за несколько минут, если речь идет о контроле наличия 220v, - блок питания (c USB выходом, например) и модуль реле. Втыкается в розетку рядом с устройством и используется как обычная сухой контакт (кнопка) с командой digitalRead[]. Далее по сложности изготовления идет что-нибудь на оптопаре (через пару резисторов в 220v или через тот же БП). Подключается так же - прикидываясь сухим контактом.
Поддержку PZEM я не выкидывал - это точно. Но работает только первая версия. Товарищ, которому очень сильно нужна была поддержка второй версии железа, на связь более не выходил. А мне имплементация поддержки с покупкой за свой счет девайса, который потом будет лежать в ящике, как-то не особо нужна.
Zabbuino со скрипом затащена на ESP8266 и ESP32. Будет ли работать стабильно - не знаю, с ESP-шками регулярных дел не имею. 100% дублирование функционала AVR в ESP-версии обеспечить не удастся, но по большей части всё должно сохранится.
С ключем разобрался, просто нужно было выставить Тип информации - Числовой(с плавающей точкой)
Подключил Ардуино к Микротику, а микрот не хочет ему присваивать IP.
Прописал статику и в журнанале ART.
Все равно не хочет.
Ну, не знаю. Смотреть надо на систему в целом, телепатией я не владею. Одно является фактом - прошивка работает.
Здравствуйте.
Меняю вот тут :
// Zabbuino's IP address
#define NET_DEFAULT_MAC_ADDRESS {0xBE,0xAD,0xEB,0xA8,0x00,0xE3}
#define NET_DEFAULT_IP_ADDRESS {192,168,0,227}
#define NET_DEFAULT_GATEWAY {192,168,0,1}
#define NET_DEFAULT_NETMASK {255,255,255,0}
На нужный мне адресс.Загрузаю на Ардуино,после загрузки не меняется адресс,остается 192.168.0.227.
Стоит Ethernet Shield для Arduino, W5100.
Что делаю не привильно ?
#define FEATURE_EEPROM_ENABLE, наверняка, активирован. Настройки при первом запуске сохраняются в EEPROM, потом могут модифицироваться по сети. Новые настройки перезаписываются на место старых при процедуре Factory Reset, например (описана в документации, нужен один проводок).
Да,стоит #define FEATURE_EEPROM_ENABLE.
Оставил только один провод,подключеный к ноуту.
Перезалил скетч и все равно адресс не изменился.
Нажимал кнопку Factory RST.Заливал заново,адресс все равно не менялся.
Или за какой один провод Вы имеете ввиду?
Кнопку надо нажать при запуске и держать. И я вместо кнопки использую простой проводок GND - D8, если припёрло.
Если по сети менять не собираетесь настройки, отключите EEPROM feature - так будет проще жить.
Добрый день!
Если вдруг у кого возникнит проблема что при подключении Ардуино + Сетевой модуль Ethernet Shield W5100 в локальную сеть,не будет пинговаться.
Воспользуйтесь вот этим советом:https://www.drive2.ru/b/465851807768249377/
Уважаемый sadman41,
в первую очередь хочу сказать Вам спасибо за Zabbuino, это, пожалуй, лучшее, что я видел для ардуино за всё время. Надеюсь, вы не бросите этот проект.
У меня вопрос про DS18B20 и Zabbix 4.x, они почему-то не хотят дружить, а этот датчик один из самых популярных и востребованных. Причем если делать по Вашему совету айтем с ключем DS18x20.Temperature[2,9] то первый в цепочке датчик действительно отвечает корректно, но если добавить еще и адрес датчика, то получаем -136. Ключ ow.scan[2] тоже ничего не выдает (точее ошибка Warning: Message from 192.168.1.10 is longer than expected 19 bytes. Message ignored. Из консоли результат аналогичный.
Уверен, вы знаете, как это исправить :) Перейти обратно на Zabbix 3.4 не вариант.
Очень прошу Вашей помощи, без Вас нам не справиться!
C ow.scan[] проблема есть, но с датчиками (адресными и безадресными) явно не наблюдается.
sadman41,
Спасибо большое за ответ, Вы мой спаситель, а я идиот )))
прописывал адреса датчиков в формате Linux, а Arduino ждет свой формат...
если в Linux (RPi) датчик имеет, например, адрес:
28-021391771f30
то в Ардуино это:
0x28, 0x30, 0x1F, 0x77, 0x91, 0x13, 0x02, 0x48 или 0x28301F7791130248
как считаются последние две цифры чексуммы я не знаю, но по виду это адрес наоборот и чексумма.
и Zabbuino, естественно, ждет второй вариант адреса... возможно кому-то это поможет, надеюсь я не один такой, кто определяет адреса датчиков с помощью Raspberry Pi )))))
Отсюда у меня к Вам второй вопрос, можно ли как-то починить OW.SCAN или в 4.х он не будет работать никогда по каким-то объективным и не зависящим от Вас причинам? Если бы он работал, этой досадной ошибки возможно можно было бы избежать.
Еще раз спасибо!
прописывал адреса датчиков в формате Linux, а Arduino ждет свой формат...
если в Linux (RPi) датчик имеет, например, адрес: 28-021391771f30
то в Ардуино это: 0x28, 0x30, 0x1F, 0x77, 0x91, 0x13, 0x02, 0x48 или 0x28301F7791130248
как считаются последние две цифры чексуммы я не знаю, но по виду это адрес наоборот и чексумма.
У Ардуино никакого "своего формата" для устройств 1-wire нет. Применяется стандарт (см. в статье): У каждого устройства 1-Wire есть 64-разрядный идентификатор (ID). Он состоит из 8-разрядного кода семейства, который идентифицирует тип устройства и поддерживаемые им функции, 48-разрядного серийного номера и 8-битного поля кода циклического избыточного контроля (CRC-8).
То, что библиотеки в Linux занимаются самодеятельностью (если это так) - беда, конечно.
Отсюда у меня к Вам второй вопрос, можно ли как-то починить OW.SCAN или в 4.х он не будет работать никогда по каким-то объективным и не зависящим от Вас причинам?
Да, я подфиксил. Забирать там же, на гитхабе. Но, если Zabbix SIA продолжит заниматься развитием IoT-направления в том же стиле, что и сейчас - прошивки будут влезать только в Мегу или вообще никуда не будут влезать.
Ура! Всё заработало! Сам поправил по образу и подобию нового корректного service.cpp из мастер-ветки гитхаба и теперь ow.scan и в zabbuino 1.3.1 работает ) Спасибо!!!
_stream.print('\n');А насчет адресов датчиков DS18B20. Вот как их видит Raspberry Pi:
А насчет адресов датчиков DS18B20. Вот как их видит Raspberry Pi:
Ничего с этим не могу поделать.
И, если бы Вы заглянули в руководство, на которое я потратил изрядно времени, то в описании ключа могли бы увидеть пример запроса (вместе с форматом записи DS18x20 ID).
Понятно, что на формат RPi Вы не влияете. Ваше, отличное, кстати, руководство я читал и даже очень внимательно, но согласитесь,
0x28021391771F30 и 0x28301F7791130248
выглядят весьма похоже, хотя это два разных формата одного датчика... вот и не заметил подвох, который выявился только благодаря вашей помощи, за что Вам еще раз большое спасибо!
Пользуясь случаем спрошу, какие планы у Вас по дальнейшему развитию платформы? Когда планируете перенос изменений эксперементальной ветки в основную?
но согласитесь, 0x28021391771F30 и 0x28301F7791130248
выглядят весьма похоже, хотя это два разных формата одного датчика...
Один какой-то коцанный. Ну, да это вопрос к пейсателям драйвера Linux. За всеми не уследишь.
Встречный вопрос - что Вы ожидаете увидеть при переносе экспериментального бранча в мастер? Радикально ничего не изменится, в принципе. Сократить размер прошивки, в чём была основная идея следующего релиза, не удалось, так что изменения вовсе могут быть незаметны для простого пользователя.
Планы же, в принципе, есть. Только нет заинтересованных в них лиц.
Встречный вопрос - что Вы ожидаете увидеть при переносе экспериментального бранча в мастер? Радикально ничего не изменится, в принципе. Сократить размер прошивки, в чём была основная идея следующего релиза, не удалось, так что изменения вовсе могут быть незаметны для простого пользователя.
Планы же, в принципе, есть. Только нет заинтересованных в них лиц.
Судя по логу на гитхабе, в 1.3.1 довольно много изменений, по сути это две очень разных версии по коду. У меня стоит 1.3.1 и после того, как пришлось самому переносить в неё изменения для работы ow.scan подумалось, что было бы лучше иметь одну ветку, раз в экспериментальной сейчас нет ежедневных/еженедельных билдов, она вполне заслуживает стать основной, уступив место 1.3.2 для будущих идей ;)
И не соглашусь с Вами, что нет заинтересованных лиц, возможно вы судите по низкой активности на этом форуме? Вероятно, что Ваш продукт уже настолько хорош, что многие его успешно используют и у них не возникает необходимости задавать вопросы. К тому же, мониторинг Zabbix штука сама по себе очень специфичная, и его основые пользователи не совсем из мира Arduino, а больше из среды сетевого айти и резонанс проекта был бы выше именно на ресурсах данного направления (habr, форумы zabbix, reddit и т.д.). Я сам далеко не сразу нашел этот форум, где мы сейчас общаемся, на гитхабе нет четкого указания и ссылки, где можно задать вопрос автору (кроме почты и Я.Мани, других контактов я не нашел). Кстати, Я.Мани есть далеко не у всех... пэйпал и/или карточка имели бы больший успех, кто-то на хабре это даже тестил )
Извините, что немного поумничал, но я вижу, что вы настроены писсиместично, и боюсь, что вы забросите этот прекрасный проект. Я, к сожалению, не программист, а так бы с удовольствием подключился бы к разработке. В любом случае спасибо вам за этот труд, вы сделали больше всех для связи zabbix с физическим миром!
Судя по логу на гитхабе, в 1.3.1 довольно много изменений, по сути это две очень разных версии по коду. У меня стоит 1.3.1 и после того, как пришлось самому переносить в неё изменения для работы ow.scan подумалось, что было бы лучше иметь одну ветку, раз в экспериментальной сейчас нет ежедневных/еженедельных билдов, она вполне заслуживает стать основной, уступив место 1.3.2 для будущих идей ;)
И не соглашусь с Вами, что нет заинтересованных лиц, возможно вы судите по низкой активности на этом форуме?
Не только. Гитхаб даёт статистику по бэклинкам и я вижу откуда приходят люди и в каких количествах. Странно, что Вы не нашли тему на форуме Zabbix - по запросам типа "Arduino Zabbix" в яндексе она не первая, но в тройке лидеров.
То, что продукт специфический - верно и с этим нельзя не согласиться. Мало кому из ардуинщиков удастся разобраться в Zabbix, а Zabbix-одов - в ардуине.
Кстати, Я.Мани есть далеко не у всех... пэйпал и/или карточка имели бы больший успех, кто-то на хабре это даже тестил )
Тестить - это одно, а реальность - другое. Сначала у меня висел пэйпал, но когда он начал меня заваливать каким-то безумными требованиями предоставить удостоверяющие документы - я просто закрыл свой аккаунт у них.
Вы упомянули датчик PZEM-004T, у китайцев сейчас продается версия 3.0 с измененным (как они пишут) протоколом связи - теперь это стандартный Modbus-RTU. Ардуино его вроде бы поддерживает. В текщей реализации поддержки этого датчика в Zabbuino 1.3 аппаратная версия датчика с Modbus-RTU будет работать?
https://ru.aliexpress.com/item/33043137964.html?spm=a2g0o.cart.0.0.7e833c004kOmb6
В v1.3 не будет.
Modbus был в планах, но в качестве "чего бы ещё такого присобачить". Но, особой потребности нет, поэтому фактически к реализации даже и не приступал.
Очень жаль, ведь Modbus используется во всей современной автоматизации, позволяет использовать RS-485 и т.д. Есть ли шанс, что вы всё же прикрутите его к своему проекту? :)
Вероятность есть всегда. Вопрос исключительно в мотивации.
Вопрос всегда в мотивации )) Например, безвоздмездное предоставление вам этого датчика с Modbus-RTU интерфейсом могло бы сподвигнуть вас на оперативную разработку решения? ;)
Нет, мне его в хозяйстве некуда пристроить. На интеграцию надо 2-3 рабочих дня (в лучшем случае) потратить. Ненужный датчик за 800р этого явно не покрывает.
Тогда сами напишите, о какой достаточной мотивации идет речь, чтобы нам тут не гадать... устроим кикстартер ))
Тогда сами напишите, о какой достаточной мотивации идет речь, чтобы нам тут не гадать... устроим кикстартер ))
Ну, смотрите: вы всегда можете точно определить время выполнения работы, которая не является основной по профилю? Наверняка - нет.
Читали ли Вы что-то про модбас? Представляете его полную функциональность (форматы отдаваемых чисел, порядок следования байт в регистре и т.д. и т.п.), которая скажется на трудоёмкости реализации и добавочном размере прошивки? Почитайте, подумайте - имеет ли смысл полностью его вкрячивать? Наверняка - нет.
Т.е. на сложность определения затраченного времени накладывается ещё не проработанная концепция "усечения осетра". А теперь решите уравнение (X+Y)*Z, где известно только Z (судя по разделу "ищу исполнителя" - оно составляет 3т.р. в день на данный момент).
И не подумайте, что я что-то выторговываю там или глазки строю. С библиотечкой modbusRTU задача действительно решается на раз-два. Ну, и где-то 30-40% ресурсов ATMega328 будет израсходовано. Это непозволительно много, так как постоянно поджимает сетевая часть (в том числе благодаря изменениям, которые вносит Zabbix SIA в свою протокольную часть). Сейчас минимальная часть (ядро) системы в Progmem Space - ~19кб. Это с W5100. С ENC28J60 - ~24кб. Т.е. около 60-75% ресурса популярного и дешёвого Ардуино-МК. Модбас, всунутый с библиотекой, - 90-115% ресурса. Неприемлемо. Желательно по модбасу уложиться в 10-20% чтобы осталось ещё хоть на какой-то градусник или на будущее.
Вдавливание же модуля с минимально достаточным функционалом в 10% ресурсов МК - это процесс с реально непрогнозируемым финалом.
Тогда сами напишите, о какой достаточной мотивации идет речь, чтобы нам тут не гадать... устроим кикстартер ))
У меня появилась одно соображение насчёт того, как на основе взаимовыгодного сотрудничества вкрячить Modbus в прошивку. Если интересно - адрес email на github-e.
Здравствуйте.
Столкнулся с такой проблемой,что раз в 3 дня Ардуино зависает и приходиться его вручную перезагружать по питани.
Может кто подскажет как быть с этой проблемой?
Добрый день, есть задача получить в zabbix сигнал в случае пропадания питания на устройстве. Подскажите какое оборудование будет оптимально использовать для этой задачи на текущий момент, для вашей прошивки. В первом посте у вас указано использование Peacefair PZEM-004, но его нет на гитхабе в списке поддерживаемых, плюс сейчас появились новые версии. Спасибо.
Самое наипростейшее, что собирается за несколько минут, если речь идет о контроле наличия 220v, - блок питания (c USB выходом, например) и модуль реле. Втыкается в розетку рядом с устройством и используется как обычная сухой контакт (кнопка) с командой digitalRead[]. Далее по сложности изготовления идет что-нибудь на оптопаре (через пару резисторов в 220v или через тот же БП). Подключается так же - прикидываясь сухим контактом.
Поддержку PZEM я не выкидывал - это точно. Но работает только первая версия. Товарищ, которому очень сильно нужна была поддержка второй версии железа, на связь более не выходил. А мне имплементация поддержки с покупкой за свой счет девайса, который потом будет лежать в ящике, как-то не особо нужна.
Good news, everyone. Может быть.
Zabbuino со скрипом затащена на ESP8266 и ESP32. Будет ли работать стабильно - не знаю, с ESP-шками регулярных дел не имею. 100% дублирование функционала AVR в ESP-версии обеспечить не удастся, но по большей части всё должно сохранится.
Тестовая версия v1.5 здесь.