SS7 blog

Статуса е обогатен с нови данни за температура, влажност и осветеност.

В близко бъдеще ще има данни за това каква ел.енергия се консумира за осигуряване на показаните температури . Чудя се дали да сложа и резултатите от датчиците на присъствие, ама за сега не ми се ще да са публични

Незнайно защо (абе знае се) повечето производители на системи за домашна автоматизация се стремят да затворат максимално системата си, така, че да не бъде лесно интерфейсвана към други системи и/или управление.

Това разбира се не е чак толкова голям проблем, защото решение винаги се намира.  Споменатите данни се осигуряват от датчиците на една система, която производителя се е постарал да затвори твърде добре. Отгоре на всичкото се прави на леко недоразбрал , когато го питат за протоколи и други подробности . Навярно заради проблеми с превода

както и да е – това упражнение е само за спорта. Вече имаме данните за околната среда в и извън къщата,  остава да се направи същинската част – управлението.

Ама не управление, като например да си пуснеш климатика или лампата с дистанционно, а задаване на параметри на системата – т.е. задаване на желаната температура в стаята , пък автоматиката се грижи за останалото. Същото е и при осветлението – ще се задава желана осветеност, пък железата сами ще решават коя лампа и на колко процента да пуснат. Да не говорим, че като няма хора в стаята, всичко ще се гаси само (икономията майка на мизерията) .

Следваща стъпка е интерфейсване (писане на драйвер) за други системи за автоматизация. Някои от тях са отворени, за други знам протокола за достъп до железата, т.е. би трябвало да е по-лесно.

То по книгите си пише – Потребителски интерфейс <–> програмна логика  <–> хардуер .

С максимум абстракция от хардуера  и интерфейса. Т.е. сменяш само един драйвер и целия софтуер продължава да работи с друга хардуерна система. Сменяш втори драйвер и работи с нов потребителски интерфейс, например друго дистанционно.

Така се прави удобно за интегратора, за съжаление на повечето производители не им изнася това спазване на добрите инженерни практики.

Аз може би имам прекалено големи изисквания за домашната автоматизация, но според мен една такава система задължително трябва да измерва консумираната енергия от жилището, по възможност разбито по стаи и консуматори.

Имам и още куп други изисквания, но за тях по късно. Тези дни попаднах на много добър сайт , който показва каква трябва да бъде една почти идеална система за домашна автоматизация.

От него пък попаднах на производител на ZigBee устройства, измерващи консумацията от всеки контакт. За което винаги съм мечтал , само дето не ми се полагат допълнителни жици до всеки един контакт. Цените са много,много добри, даже бих казал – без пари.

В най-скоро време ще се оборудвам с Home Basic set , съотверно цялата консумирана енергия (която хич не е малко) ще бъде качена real time тук , подобно на външната температура. Освен това устройствата имат реле и могат да ключват и изключват консуматори с цел икономия на енергия. Отгоре на всичко има open source софтуер управление и отчитане под линукс.

Следващата стъпка ще бъде realtime отчитане на температурите в цялата къща, с последващо регулиране на отоплението в зависимост от присъствието на хора и ефективността на отоплителния уред. Например – влиза човек в необитаемата от няколко дена къща и автоматиката включва подово + климатик за бързо достигане на нормална температура, след това изключва подовото (щото е скъпо) и оставя само климатика.

Въз основата на данните за вътрешната и външната температури и консумираната енерги, пък ще може да се пресмята ефективността на топлоизолацията на къщата, да се взима в предвид топлоемкостта на сградата и да се оптимизира отоплението .

Следваща стъпка би било автоматизиране на осветлението в зависимост от присъствие на хора и слънчево греене (това всъщност вече го има реализирано , но кода е затворен и не мога да променям нищо)

Всъщност една добра система за домашна автоматизация не се нуждае от дистанционно .

Енергоспестяващите лампи са една голяма заблуда – може да спестяват ток, ама и не светят.

Тези два дни докато си играх със системката за автоматизация, установих, че 20W енергоспестяваща лампа осигурява 5 lx осветеност, а 75W обикновена лампа – 20 lx осветеност.

Сравнението изобщо не е в полза на енергоспестяващата лампа. За да осигури 20 lx осветеност, тя би трябвало да е 80 W , срещу само 75W на обикновената лампа.

Светодиодните лампи пък са “мижи да те лажем” , не може дори да ги хване датчика за осветеност.

Отгоре на всичко, всякакви лампи с електроника в тях не подлежат на управление по осветеност (димиране) . Абе подлежат, ама мамата си трака – регулирането е в много тесни граници, а освен това при ниско напрежение започват да трептят изключително гадно, поради липса на инертност.

Всъщност по-принцип могат да се регулират добре, но не и с обикновени димери, работещи на фазов принцип. За правилно регулиране би трябвало да се използва PWM с по-висока честота, така, че окото да не забележи мигането.

Интереснообаче е как ще понесе димирането луминисцентна лампа с обикновен баласт (дросел) . Индуктивността на дросела би трябвало да не позволява прекъсване на тока през лампата, съответно и доста по-малко (или дори липса на)  мигане . Утре ще пробвам, щото нямам под ръка луминисцентна лампа.

Вече минавам на малко по-високо ниво от pico ip контролерчето.

Ето демо на домашна автоматизация , използваща ZigBee стандарта, с доста богати възможности за създаване на правила , датчици на температура , дистанционни , дори и мини метео станция. Всичко това работи и е пуснато в действие само за няколко часа :

Системата не само е интелигентна, но и самообучаваща се в зависимост от поведението на хората в жилището – пуска, гаси и регулира сама осветлението, щорите и отоплението. При отсъствие изпълнява ролята на охранителна система (може да се върже съм СОТ фирма) и изпраща СМС съобщения при задействане. Осигурява пълен лог на всички деиствия – ръчни и автоматични , с дата, час и вид действие.

Управлява се с дистанционно (може и дори няколко ) локално и през интернет (httpS) дистанционно. Чакам документация за ИП протокола за управление и ще има осигурено управление от “прочутото” дистанционно на Philips – Pronto.

Засега не мога (по скоро не трябва) да пусна тестов демо достъп , но и това ще стане

Ако сте заинтересовани, звънкайте на тел. 02 – 846 8087 , ще Ви осигурим демострация на живо и/или тестов демо достъп през интернет. Системата е дори относително евтина

п.с.

Брей, още съм на първо място в гугъла по “домашна автоматизация” , ама мога да стана пръв и по други думички , ако бъда подразнен още малко. btw оня ден видях един колега да смята на калкулатор колко е 0х01 (шеснайсетично) в десетична бройна система . Едно си е едно във всички бройни системи, да си знаете .

Напоследък се нагледах на противоположността на “How to …..” .

Или как заради не дотам добро проектиране се стига до изгъзицата да се пише програма обработваща MAC фреймофе на JavaScript . От която задача аз изпаднах в потрес, който още ме държи.

Та имаме система за автоматизация, която в общи линии използва за преносна среда захранването (powerline) , стъпила е на един архаичен стандарт – KNX/EHS и е развита (според мен) в неправилна посока.

Всички знаем, че една система за автоматизация се състои от управляваща част , изпълнителна част и датчици. И общо взето е централизирана – цялата управляваща логика е на едно място, съответно с добър процесор/контролер , а останалата част е максимално проста – на изпълнителната част и датчиците не им трябва мозък – трябва им само адрес и евентуално да потвърждават изпълнена команда.

Да , обаче в нашия случай не е баш така. “Интелигентно” е дори това, което не трябва – например прост ключ за пускане/спиране . А управляващата част (централната) просто липсва. Т.е. имаме някакъв вид разпределена система, при която всяко устройство може да си говори с всички останали.

Освен, че не виждам смисъл даден ключ да може да си говори с друг ключ, това може да докара сериозни проблеми за достъпа до медията на MAC ниво, комуникацията е в килохерцовия обхват и скоростите са килобити в секунда.

Направен е опит функционалността на централния контролер (който както казах липсва) да се направи в интерфейсните модули. Такива има няколко – IR , GSM , bluetooth (сериен) и сериен – RS232 . Все още не знам каква управляваща логика има там (освен в серийните интерфейси – там няма никаква).

Сегашната задача е да се направи IP интерфейс (дистанционното има wireless , JavaScript и socket в JavaScript-a) . И как е направен интерфейса ? Ами чудно – IP to RS232 -> RS323 to powerline , напълно неинтелигентен . В допълнение трябва етернет мрежа и безжичен AP .

Как бих го направил аз ? Хм , по възможно най-лесния начин (и най скалируемия) – един Alix (имаме етернет, имаме minipci за безжична карта, имаме и сериен порт) , Alix-a струва малко по скъпо от IP to RS323 адаптера. Щях да сложа един линукс на Аликс-а , да пусна безжичната карта и да наблъскам там целия необходим код за управление. Дистанционното щеше да си говори с него на приложно ниво, с команди от вида “SET” , “GET”. И един RS232 to powerline .

Е предпочитам да парсвам МАК фреймове със С и под линукс, отколкото на JavaScript и под непозната ОС, без никакви средства за дебъгване. Да не говорим, че второ дистанционно (и десето ако трябва) ще се добави без никакви проблеми. Хе, ще ми се да питам (и ще питам) разработчика на настоящата система КАК ПО ДЯВОЛИТЕ ЩЕ ДОБАВИ ВТОРО ДИСТАНЦИОННО ? Разбира се той ще измисли workaround , работещ и неефективен workaround , вместо да вземе да проектира както трябва.

Като говорехме за проектиране, някой виждал ли е комуникационен протокол, при който адресите са някъде към края на фрейма , при това не на фиксирано място, а зависещо от нещо си. Е аз видях вече

Би трябвали всеки, който седне да проектира такъв протокол да погледне етернет спецификацията и да си набие в главата : ИЗТОЧНИК , ПОЛУЧАТЕЛ, ДЪЛЖИНА , ДАННИ ! При това адресите да са с ФИКСИРАНА , а не с променлива дължина (щото и това го има хе,хе).

Мани,мани, мога да изпиша страници.

За капак на всичко, дистанционното TSU9400 (което струва между другото около 1000 лв) прави един номер, който скапва иначе добре написания (от Филипс) TCP клиент.

Та , сокета при него има callback функция .onConnect и променлива .connected. Интересната част е, че лежащия от долу ОС сетва .connected = true, но извиква .onConnect фунцията, когато сметне за добре , ако е натоварен процесора – дори след секунди. През това време всичко що работи със сокета си мисли, че сокета е конектнат и пише и маже смело в него. Писането минава, с изключение на първото писане, щото пък TCP клиента по ред причини го слага във .onConnect функцията. И настава едно мазало – немам думи.

Та идеята на целия тоя дълъг пост е, че когато нещо е проектирано добре (например ПИКОИП), са необходими само 10-на реда код, за да го интерфейсне всеки с минимална грамотност, към каквото и да е, докато в обратния случай са необходими поне 300 реда код (и то на JavaScript) , да не говорим пък, че хората, които могат да го направят се броят на пръстите на едната ръка.

PicoIP на Неомонтана е доста добър контролер, предназначен основно за управление на комутатори, но с 16-те си изходни порта и 8 входни (10 битов АЦП) има широко поле на приложение за всякакъв вид автоматика.

Голямо предимство е управлението му чрез snmp , т.е. дистанционно може да се управляват до 16 консуматори и да се мерят до 8 входни аналогови величини.

В момента правя автоматизация на включването и изключването на бойлера в къщи , като в допълнение ще меря моментната консумация на ел.енергия (щото ЧЕЗ ми режат главата напоследък) и няколко температури – външна и в стаите. Включването и изключването на бойлера ще става от crontab-a в определени часове, а в допълнение ще може да се управлява и ръчно през уеб страница.

Досега съм направил четенето на съответните регистри на PicoIP и показването им в тази страница.

Предстои да сложа релетата (и контактора) за управление и няколко термистора за измерване на температурата.

Консумацията на енергия ще меря посредством измерване на консумирания ток ( с токов трансформатор) . Токовия трансформатор е от тороидален дросел от компютърно захранване с 30 намотки – т.е. трансформация 1:30 , при 30А консумация трансформатора ще дава на вторичната намотка 1 А , които пък чрез съпротивление от 2 ома ще се превърне в напрежение, удобно за измерване от PicoIP . Ще трябва да го изправя и ще меря максималната стойност на тока, която пък чрез сметки ще се доведе до ефективната, а оттам и до консумираната мощност (с умножение по напрежението).

Управлението на PicoIP през web става по следния начин :

1. Упраление на изходните портове:

включване:

#!/bin/sh

echo “Refresh: 1; url=http://ss7.dupnica.net/?page_id=1568/”
echo “Content-type: text/html; charset=iso-8859-1″
echo

echo “<html><head>”
echo ” </head>”

echo “<body>”
snmpset -v1 -c private 10.10.10.101 PortCTRL.pctrlPort3.pctrlP3pin1.0 i 1

echo “</body>”
echo “</html>”

излючване :

snmpset -v1 -c private 10.10.10.101 PortCTRL.pctrlPort3.pctrlP3pin1.0 i 0

2. Четене на данни от входните портове (променил съм MIB-овете за удобство) :

<?php

Print “Boiler is: “;
print exec(‘snmpget -v1 -c public 10.10.10.101 PortCTRL.pctrlPort3.bojler.0 -O Q -O v’);

print “<br><br>Power: ” ;
print exec(‘snmpget -v1 -c public 10.10.10.101 PortCTRL.pctrlPort6.PowerConsumption.0 -O Q -O v’);
print ” W <br>Temp: ” ;
print exec(‘snmpget -v1 -c public 10.10.10.101 PortCTRL.pctrlPort6.Temp.0 -O Q -O v’);
print ” C<br>OutTemp: ” ;
print exec(‘snmpget -v1 -c public 10.10.10.101 PortCTRL.pctrlPort6.OutsideTemp.0 -O Q -O v’);
print ” C”;
print “<br><br>”;

?>

Не съм много добър в програмирането (не съм писал нищо от десетина години) , така, че не ме критикувайте

Скоро ще има действителни данни