Вместо това, ще напиша малко размисли относно електронното банкиране на Fibank. Не пиша това с упрек, макар и да е дразнещо, а с идеята за конструктивна критика. Fibank са доста активни в социалните мрежи и вероятно ще попаднат тук рано или късно (дори ще взема да ги ping-на в twitter).

Според блога си, са сред пионерите на виртуалното банкиране в България. Предполагам, че това наистина е така. Чел съм доста хвалби касаещи тяхното Интернет банкиране по блогове и ред сайтове, чувал съм ги и лично от приятели и познати, но сега, когато го (имам идея да го) ползвам по-активно намирам някои липси.

• Не виждам каква е логиката в това, да мога да открия сметка или депозит чрез електронното банкиране, но да не мога да я закрия и да трябва да отида лично до някой клон.
• Защо има два различни сайта my.fibank.bg и e-fibank.bg. Не можеше ли когато не използваш сертификат e-fibank.bg да е с ограничената функционалност на my.fibank.bg?
• Защо не мога да регистрирам телефона си за получаване на информация, а е необходимо да попълвам декларация / заявление лично в някой клон.

Според този кратък цитат от техния сайт:

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

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

Всички клиенти на Виртуалния банков клон на Fibank – физически и юридически лица, получават автоматично безплатнo SMS съобщение за всеки техен превод, извършен през Виртуалния банков клон.
В случай че не желаете да се възползвате от тази възможност на услугата, можете да заявите отказ от получаване на SMS известия, като подадете лично молба в клон на Fibank.

Или с други думи би трябвало да съм автоматично абониран за въпросната услуга. Не знам какво се има предвид под „превод“ в случая и дали онлайн плащания извършени от моята сметка се броят за преводи, или става дума за изрично направени преводи през виртуалният им клон, но SMS-и не съм получавал. Но както и да е, по-фрапантното в случая е, че за да се откажеш от въпросните известявания отново е необходимо личното посещение на техен клон. Тук поне има последователност за разлика от откриването / закриването на сметка и при двете е необходима разходка.

Не че имам против да се насладя на красивите момичета по фронт офисите им. Но когато свободното ти време е ограничено, висенето на опашки по клоновете не е кой знае колко привлекателно. Още повече, ако нямаш клон на банката наблизо (макар че вероятно са банката с най-много клонове) или пък не можеш да го посетиш в работно време (все пак то вероятно съвпада с твоето такова, макар и по МОЛ-овете да има изключения). Все пак дори и те са посочили тези неща, като една от основните прични за използване на електронно банкиране.

Може би грешката е в мен, но под виртуален банков клон и електронно банкиране, моето виждане е, че в общи линии би трябвало да мога да правя всичко, което мога да направя и във физически клон на банката. Мога да предположа, че това не е възможно и има услуги, които налагат личното ми присъствие. Но наистина не ми е понятна причината за това да мога да извърша дадена услуга, но не ѝ нейната противположност. Вероятно защото не съм от Лондон.

От това, което прочетох се надявах да ми се падне Omnikey четец, но в избраният от мен офис на ЦКБ такива нямаше – единствената опция беше ACS. Понеже напоследък съм мързелив, а и ми трябваше спешно рискувах и го взех. Последното след попълването на един тон документация от момичето в офиса, което беше леко неориентирано, изглежда нямаше кой знае какъв опит с издаване на сертификати, но с малко помощ от приятели (с цената от две телефонни обаждания) все пак се справи.

И така, за мен остана да изчакам края на работния ден, да се прибера и да видя какво ще се получи. Ами смело мога да заявя, че четецът работи out of the box с ccid драйверът по подразбиране.

pcscd сървисът е стартиран:

[Nick@Pegasus ~]$ systemctl status pcscd.service
pcscd.service - PC/SC Smart Card Daemon
Loaded: loaded (/lib/systemd/system/pcscd.service; disabled)
Active: active (running) since Tue, 22 Nov 2011 20:56:10 +0200; 2h 9min ago
Main PID: 8758 (pcscd)
CGroup: name=systemd:/system/pcscd.service
└ 8758 /usr/sbin/pcscd -f

Исталирани са следните пакети:

[Nick@Pegasus ~]$ yum list pcsc-*
Installed Packages
pcsc-lite.x86_64                        1.7.4-6.fc16                  @fedora
pcsc-lite-ccid.x86_64                   1.4.5-1.fc16                  @fedora
pcsc-lite-devel.x86_64                  1.7.4-6.fc16                  @fedora
pcsc-lite-libs.x86_64                   1.7.4-6.fc16                  @fedora

[Nick@Pegasus ~]$ yum whatprovides pcsc-lite
pcsc-lite-1.7.4-6.fc16.x86_64 : PC/SC Lite smart card framework and applications
Repo        : fedora

[Nick@Pegasus ~]$ yum whatprovides pcsc-lite-ccid
pcsc-lite-ccid-1.4.5-1.fc16.x86_64 : Generic USB CCID smart card reader driver
Repo        : fedora

Ето и как се разпознава самият четец (dmesg output):

[787202.753102] usb 1-1.5.4: new full speed USB device number 13 using ehci_hcd
[787202.841264] usb 1-1.5.4: New USB device found, idVendor=072f, idProduct=90cc
[787202.841267] usb 1-1.5.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[787202.841269] usb 1-1.5.4: Product: CCID USB Reader
[787202.841270] usb 1-1.5.4: Manufacturer: ACS
[789782.064529] usb 1-1.5.4: USB disconnect, device number 13

И малко по-подробно (lsusb -vd):

lsusb -vd 072f:90cc
 
Bus 001 Device 015: ID 072f:90cc Advanced Card Systems, Ltd ACR38 SmartCard Reader
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0         8
  idVendor           0x072f Advanced Card Systems, Ltd
  idProduct          0x90cc ACR38 SmartCard Reader
  bcdDevice            1.00
  iManufacturer           1 ACS
  iProduct                2 CCID USB Reader
  iSerial                 0
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           93
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           3
      bInterfaceClass        11 Chip/SmartCard
      bInterfaceSubClass      0
      bInterfaceProtocol      0
      iInterface              0
      ChipCard Interface Descriptor:
        bLength                54
        bDescriptorType        33
        bcdCCID              1.00
        nMaxSlotIndex           0
        bVoltageSupport         7  5.0V 3.0V 1.8V
        dwProtocols             3  T=0 T=1
        dwDefaultClock       4000
        dwMaxiumumClock      4000
        bNumClockSupported      0
        dwDataRate          10752 bps
        dwMaxDataRate      344100 bps
        bNumDataRatesSupp.      0
        dwMaxIFSD             247
        dwSyncProtocols  00000000
        dwMechanical     00000000
        dwFeatures       00010030
          Auto clock change
          Auto baud rate change
          TPDU level exchange
        dwMaxCCIDMsgLen       271
        bClassGetResponse      00
        bClassEnvelope         00
        wlcdLayout           none
        bPINSupport             0
        bMaxCCIDBusySlots       1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0008  1x 8 bytes
        bInterval              16
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
Device Status:     0x0000
  (Bus Powered)

Моделът на картата ми е T&S DS/2048 (L), което налага инсталирането на два допълнителни пакета от хранилището на Инфонотари, a именно – bit4id-ipki и infonotary-scardmanager.

Остава само настройката на browser-а, който в случая е firefox. Сертификатът може да се инсталира директно от линка изпратен от Инфонотари чрез e-mail, а за улеснение на конфигурацията може да се добави следният firefox add-on – InfoNotary Configurator for Mozilla, . Ако при отварянето на тестовият линк (тестът може да бъде направен и от Preferences –> Signature Test на добавката на Инфонотари), отговорът е Data Accepted, то всичко е наред и можем да подписваме на воля.

Допълнителна информация:

Загубих доста време да разбера какъв е точният модел на четеца. Както може да се види от output-а по-горе то се разпознава като ACR38. На капачето му обаче е изписано ACR38T, а според една от техническите спецификации на сайта на производителя, а и според външният му вид, то това е ACR38DT. Според същата спецификация, въпросният четец работи с ccid, само ако е с firmware 1.12, и явно моят е такъв. В противен случай вероятно ще се наложи инсталирането на vendor драйверите.

Ето как изглежда на практика:

Полезни линкове (дадени са и в текста по-горе):

1. Използване на квалифициран електронен подпис в Mozilla Firefox за Linux
2. Използване на хранилищата на InfoNotary
3. InfoNotary Configurator for Mozilla
4. Инсталация на драйвери за четец и смарт карта в Linux

Умишлено не посочвам линк към „Инсталация на драйвери за четец и смарт карта в Linux“. Въпреки, че статията е относително актуална, то в нея има някои неточности, които могат да доведат до объркване. Освен това е и доста Ubuntu ориентирана. Но това, не е кой знае какъв проблем, освен че имената на пакетите във Fedora са други.  Проблемът е друг, че по начинът, по който е написан краят на статията, може да се остане с впечатлението, че е нужно да се инсталира и OpenSC. Това не е необходимо! OpenSC, въпреки че разпознава правилно четеца, зарежда и използва CNS драйвера. Освен това, ACS липсва от списъкa с поддържаният от проекта хардуер, но пък е споменат в списъкът с поддържани устройства от CCID.

И така в резюме: ACS ACR38DT от Инфонотари работи под Fedora 16 с Firefox 7, без да е необходимо да се инсталират допълните драйвери за картовия четец.

Рдакция /24.11.2011/: Статията във wiki-то на Инфонотари е редактирана, и е доста по-точна в момента. Така че включвам и линк-а към нея.

• Chrony заменя ntpd като основен метод за синхронизация на време
• ext4 отдавна е част от дистрибуцията, но сега ext4 драйвера се използва за монтирането и на ext2 и ext3 дялове.
• 1000 System accounts – преместване на границата между потребителски и системни акаунти от UID/GID 500, на UID/GID 1000
• Gnome 3.2
• KDE 4.7
• Много подобрения и добавени приложения свързани със виртуализацията и облачните услуги

Екипът на Fedora прави хубав жест с решението да посвети Verne  на големият Денис Ричи.

Повече подробности могат да бъдат намерени в Release Notes, Feature List и официалният анонс.

По стара лична традиция upgrade-нах от 15-та към 16-та версия посредством yum. Въпреки че не е сред официално препоръчваните начини за update, си остава най-удобният за мен. Процедурата е следната:

Импортиране на ключа:

rpm --import https://fedoraproject.org/static/A82BA4B7.txt

Update на yum:

yum update yum

Изчистване на кеш-а:

yum clean all

И самия update:

yum --releasever=16 --disableplugin=presto distro-sync

Имаше малко проблеми със счупени зависимости, та се наложи преди това да премахна:

yum -y remove kino, libnih, libmtp-hal

След това всичко мина гладко и можеше да се насладя на добрата работа на Artwork тима.

--- kannel.epel.spec    2011-10-28 16:29:01.000000000 +0300
+++ kannel.spec 2011-10-28 16:31:48.000000000 +0300
@@ -1,18 +1,18 @@
 Summary: WAP and SMS gateway
 Name: kannel
-Version: 1.4.3
-Release: 5%{?dist}
+Version: 1.5.0
+Release: 20111028%{?dist}
 License: BSD
 Group: System Environment/Daemons
 URL: http://www.kannel.org/
-Source0: http://www.kannel.org/download/%{version}/gateway-%{version}.tar.bz2
+Source0: http://www.kannel.org/download/kannel-snapshot.tar.gz
 Source1: kannel.logrotate
 Source2: kannel.init
 Source3: kannel.conf
 Source4: gw-config
 # TODO: a corresponding configure.in patch could be upstreamable?
-Patch0: gateway-1.4.3-ssldetect.patch
-Patch1: gateway-1.4.1-typesh.patch
+#Patch0: gateway-1.4.3-ssldetect.patch
+#Patch1: gateway-1.4.1-typesh.patch
 BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root
 BuildRequires: bison, byacc, flex, ghostscript
 BuildRequires: libxml2-devel, openssl-devel, zlib-devel, pcre-devel
@@ -69,9 +69,9 @@
 
 %prep
-%setup -q -n gateway-%{version}
-%patch0 -p1 -b .ssldetect
-%patch1 -p1 -b .typesh
+%setup -q -n kannel-snapshot
+#%patch0 -p1 -b .ssldetect
+#%patch1 -p1 -b .typesh
 %{__chmod} -c -x gwlib/html-entities.def # for -debuginfo, as of 1.4.3
 
@@ -147,6 +147,7 @@
 %{_bindir}/seewbmp
 %{_bindir}/wmlsc
 %{_bindir}/wmlsdasm
+%{_bindir}/decode_emimsg
 %{_sbindir}/*
 %{_mandir}/man?/*
 %attr(0750,kannel,kannel) %dir %{_var}/log/kannel/
@@ -164,6 +165,9 @@

I assumed that the two patches applied to version 1.4.3 are not necessary, because they probably are part of the svn code.

There was a build error on the first run:

RPM build errors:
Installed (but unpackaged) file(s) found: /usr/bin/decode_emimsg

so I had to add „%{_bindir}/decode_emimsg“ in the %files section.
The spec file expect the availability of the following files in the SOURCE directory: kannel.logrotate, kannel.init, kannel.conf, gw-config

The kannel.spec file can be found here.
The command used to build the rpm is:

rpmbuild -ba kannel.spec

Another way to do the trick:
http://www.blogalex.com/archives/23

Това е нещото, което ще запомня:

Your time is limited, so don’t waste it living someone else’s life. Don’t be trapped by dogma — which is living with the results of other people’s thinking. Don’t let the noise of others’ opinions drown out your own inner voice. And most important, have the courage to follow your heart and intuition. They somehow already know what you truly want to become. Everything else is secondary.

http://www.wired.com/epicenter/2011/10/jobs/all/
http://www.theregister.co.uk/2011/10/06/steve_jobs_bio_1/

Малко откъслечни мисли

Разбира се основното е забавянето от 242 дни. Както на самия CentOS 6.0 така и на Security ъпдейтите за 5.6, които също „излипсваха“ за известно време в началото на 2011.  Основната теза защитавана от разработчиците на дистрибуцията е липсата на ресурс и лошо стечение на обстоятелствата (излизането на RHEL 5.6 и 6.0 за относително кратък период). В общи линии нещата бяха представени така – Трябваше да избираме кое да направим първо, ние избрахме 5.6, а Scientific Linux 6.0, за това те ни изпревариха. Другата основна догадка сред community-то бе, че стъпките предприети от RedHat с идеята да затруднят Oracle в копирането на RHEL и предлагането на support за него, са попречили сериозно и на CentOS но разработчиците точно и ясно неколкократно отрекоха това да е проблем. Модифицираните от екипа на CentOS пакети са 11, премахнатите от CentOS пакети са 10 и е добавен 1, което както и да го гледаме е нищожно малко. Това не трябва да създава впечатлението обаче, че реализирането на CentOS е работа за 2 дни. Всеки пакет се build-ва от srpm-а предоставен от RedHat, така че несъмнено е времеемко и изисква адекватно внимание. Въпросът е в това, че пускането на предния major release (5.0) е отнело само 28 дни. Какво толкова се е променило през изминалите от тогава 4 години. Никой не знае. Дори и хора, като Dag Wieers не са наясно  (всеки ползващ RedHat дериват би трябвало да е наясно кой е той). В това и за мен се крие основния проблем – липсата на информация. Имаше неколкократни запитвания в мейл листа и официалния форум, имаше и предложения за евентуална помощ, но единственото, което се имаше насреща бяха уклончиви и на моменти дори арогантни отговори, в повечето случаи дори не от пряко ангажирани с процеса хора. Чат пат се включваше и Karanbir Singh, но без някаква кой знае каква конкретика.  Това е нещото, което ме подразни много повече от самото забавяне (за щастие нямах планирани машини за пускане в production, освен една миграция, която спокойно можех да забавя). Да не говорим че се започнаха дори и подигравки, когато се случеше поредното „побутване“ с 2 седмици на полу-официалния schedule (още по-лошото е, че дори нямаше history, просто се сменяше датата).

Силно се надявам хората стоящи зад проекта сериозно да се замислят над това случващото се и да поемат подадената им ръка, без да подхождат с високомерие, каквото на моменти се демонстрираше. Когато си вдигнал летвата толкова високо, нивото се поддържа доста трудно, особено когато ресурсът е ограничен, но е по-добре да кажеш че се нуждаеш от помощ, отколкото системно да отклоняваш адекватни въпроси с фрази от рода „Не бързайте, ще стане“.

Графично представяне, с което да обоснова горното

Инспириран от тази статия и наличната информация във Wikipedia и announce мейл листите на RedHat и дистрибуциите базирани на него направих сравнителна табличка и графика за забавянията (в дни) спрямо Redhat release-ите (започва от 4.4, понеже тогава е първият Oracle Unbreakable release).

За пресмятането на разликата в дните ползвах ето този one-line perl script:

perl -e 'use Date::Calc qw(Delta_Days); printf "%d\n", Delta_Days(first_date,second_date);'

където датите са във формат – „yyyy,mm,dd“

Таблицата:

И графично представяне на горното (клик за по-голям размер):

От друг ъгъл и с малко transparency (клик за по-голям размер):

Както се вижда основно от графиките, забавянията напоследък са постоянни и при CentOS бележат регрес, чиито апогей бе забавянето на 6-цата. Докато при SL и особено Oracle се отбелязва прогрес. Не знам колко е голям екипа на Oracle, естествено на тях им и плащат за това, но не може да им се отрече че що се касае до време се справят добре. SL е горе-долу на едно ниво с CentOS, с изключение на последните няколко release-а, където бие по точки. Техният тим е обявен на сайта им, и никак не е голям. Те също са на заплата в CERN, но по стечение на обстоятелствата мисля, че дистрибуцията не им е сред топ приоритетите. Паралелно си поддържат и около 9000 сървъра и 3000 декстоп станции по техни думи.

Та въпроса, какво става с CentOS си виси на дневен ред и си го задавам не само аз:

Matt Simmons е написал много добър пост темата тук. Понеже нямах физическата възможност да следя всеки threads в CentOS-devel мейл листа (по груби спомени бяха няколко хиляди) преди малко попаднах на ето този мейл там, в което е написано следното /което и донякъде отговаря на въпроса за забавянето само по себе си/:

This is NOT the case with 6.0.  First off, we can not use any of the
existing infrastructure to build on because we can not build on a CentOS
4 or CentOS 5 machine because of the changing of MD5SUM in the RPMs
themselves.

Secondly, the distribution will not build on the Beta (much like the 3.x
release and UNLIKE the 4.0 and 5.0 releases).  Not only that, but
upstream used many "non released" packages to build on ... packages we
can not see or get.

Now, because of those things and because we choose to stop work on 6.0
to build out 5.6 and 4.9, the 6.0 release is late.

Но няколко мейла по-натам Dag Wieers прави доста ценно включване, което и обяснява неговото оттегляне, както чувството за безизходица обзело крайните потребители след отговори от рода на „Ще стане, когато стане“, и объркването от липсата на заявка за помощ от безспорно „силната“ CentOS общност:

On Mon, 16 May 2011, Johnny Hughes wrote:

> It will be released when it is released, if you don't like it then leave. 
Before I leave this list let me take you back about 7 years to the
Whitebox mailinglist. You may not remember that Whitebox had a list of
issues of its own, no timely updates, no community effort, lack of good
communication. It was mostly a one-man-effort.

And the people on that list who were not pleased, included Johnny and
Karanbir. And it's striking (and ironic) how similar the discussions went
7 years ago. Johnny said:

   [WBEL-users] WBEL Vs Centos ? :-S
   http://beau.org/pipermail/whitebox-users/2004-December/004761.html

   "If timely updates are not a key factor for you, then WBEL is a great
   distro.  If timely updates are the most important thing you consider
   about the distro you want, then WBEL might not be a fit for you.  That
   is all I have ever said ... and I have never said it meanly."

or:

   [WBEL-users] WBEL Vs Centos ? :-S
   http://beau.org/pipermail/whitebox-users/2004-December/004740.html

   "I just think people should not have the expectation the WBEL is
   community operated, it is not.  It's NOT like debian or gentoo where
   others can get involved.  I know, I tried really hard to do so many
   times.

Karanbir said:

   [WBEL-users] WBEL ...dead?
   http://beau.org/pipermail/whitebox-users/2004-December/004684.html

   "Be a lil difficult to sell that to the IT Manager / CTO : Hang tight
   dude, its comming. Anytime now."

or:

   [WBEL-users] WBEL ...dead?
   http://beau.org/pipermail/whitebox-users/2004-December/004709.html

   "Why ? the other RHEL recompiles dont have this 'its coming, hang on'
   attitude do they ?

   If there is a security issue out there, you can put in a fairly good
   idea as to when its possible to deploy with them. Whats the scene with
   WBEL ?"

The only difference I see is that back then Whitebox had only a fraction
of users, and even less using it for critical mission, while nowadays
people rely even more on timely security updates and releases coming from
CentOS. And people expect to help and contribute to the process to make
that happen.

Which, contrary to what is stated now, was an essential part in the start
and growth of the CentOS project.

Какви са опциите?

• оставаме си с CentOS
• миграция към SL
• ползване на support и съответно RHEL
• ползване на Fedora (няма long time support)
• ползване на друга популярна сървърна дистрибуция (не- Redhat / RPM базирана)

Моят избор за момента е да остана с CentOS – е, освен ако не почна работа във фирма, която си плаща за RHEL :)  С CentOS все пак са и доста други (в това число Facebook, Amazon EC2, Tumblr). Но понеже горчивия привкус от тази история остава, при първа въмозжност ще хвърля един поглед на SL.

Като отдавна знам, че доста LAN-аджии използват PicoIP за автоматичен рестарт на оборудване по своите трасета, та предположих, че ще ми свърши работа и на мен. Налага се обаче да се комбинира и с друга джаджа правена от Нео Монтана, а именно RelayBox 2x. С оглед на това, къде работя, можеше да прибегна и до друга схема – рестарт чрез изпращане на SMS, но щеше да излезе малко по-скъпичко :)

И така след като набавихме необходимите материали, а именно:

• 1 брой PicoIP (със съответното потребителско ръководство)
• 1 брой двупортов RelayBox
• 1 брой обикновен 12V адаптер
• 1 брой мрежов кабел с нужната дължина
• 1 брой публичен IP адрес
• 1 брой дистанционно за климатик

пристъпихме към действие:

Първо направихме алфа тест на PicoIP-то и RelayBox-а. Свързването става доста лесно, единственото което е нужно е да се разгледат Приложенията на PicoIP ръководството от сайта на Нео Монтана. От него разбираме, че трябва да свържем единия канал на RelayBox-а към системния порт JP6 на PicoIP, и по-точно към 6-ти pin, който изпълнява специална функция TargetRST и към 10-ти, който естествено е GND. Наложи се естествено да захраним RelayBox-а от 12VDC конектора на PicoIP платката. Бяхме забравили да вземем кабел, та пригодихме едни кабелчета от молекс удължител за PSU. След като свързахме всичко и изтествахме Restart функцията и всичко изглеждаше напълно функциониращо оставаше да измислим как да включим климатика в цялата схема. Вариантите бяха два, директно към управляващата му платка, или чрез дистанционното. И понеже не намерихме ел. схема за първото, то сметнахме, че ще е по-лесно да направим второто.

Понеже никога не съм бил особено добър с поялника, а така или иначе не притежавам такъв, то прибегнах до помощ от приятел (колега). Ето и малко снимки от модването на дистанционното. За връзката дистанционно – RelayBox използвахме една стара изтерзана USB мишка. Ето и малко снимки от този процес (приготовление плюс изпълнение):

Остана да свържем всичко и да видим дали ще сработи. Направихме бета тест и успешно включихме и изключихме тестовият климатик няколко пъти.

Наложи се лек тунинг на настройките на Pico-то (по подразбиране прави рестарт при липса на ping към него в рамките на 6 минути). Тази функция не ми бе нужна, така че я спрях. Останалото е настройка на статичен IP адрес, естествено user и pass и инсталиране на системата на място. На по-късен етап може да се добави и следене на текущата температура в стаята и състоянието на климатика (включен/изключен), но на този етап реших да не усложнявам схемата, след като така или иначе имам начин да разбера дали токът е спирал или не. Ето и как изглежда самият web interface за управление на PicoIP:

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