Inteligentny Dom eHouse. Programowanie w językach C, C++, Object C pozwala na integrację inteligentnego domu eHouse z prawie dowolnym sprzętem i systemami operacyjnymi.
Jest to jeden z najbardziej niskopoziomowych języków programowania (w zasadzie drugi po assemblerze).

Dzięki temu, oprogramowanie pisane w dowolnych wariantach C jest:

• Najszybsze z możliwych
• Najmniej obciążające system mikroprocesorowy (procesor)
• ma najmniejsze wymagania odnośnie wydajności i szybkości sprzętu, na którym pracuje
• pozwala na łatwą adaptację w dowolnym systemie operacyjnym (w zasadzie każdy system posiada kompilator C) umożliwiający tworzenie oprogramowania na dowolną platformę
• może pracować na dowolnym sprzęcie wyposażonym w procesor: komputery PC, mikro i mini komputery, płyty komputerowe, sterowniki mikroprocesorowe i mikrokontrolery

Aby ułatwić integrację sterowników inteligentnego domu eHouse z oprogramowaniem indywidualnym tworzonym przez użytkowników końcowych, vendorów, firm współpracujących – zamieszczamy szablony aplikacji do tworzenia oprogramowania w językach C, C++, Object C.

Daje to możliwość tworzenia oprogramowania na dowolne systemy operacyjne nawet bardzo egzotyczne:

• Amiga (AmigaOS, AROS, MorphOS)
• Apple (iOS, Mac OS, Apple DOS, ProDOS, Darwin, GS/OS, OS X, OS X Server )
• Atari ST (Atari TOS, MultiTOS, FreeMiNT, MagiC)
• Be (BeOS, BeIA , NewOS/Haiku, YellowTAB, Zeta)
• DEC/Compaq (AIS, OS-8, RSTS/E, RSX, RT-11, TOPS, VMS/ OpenVMS)
• Google (Android, Chrome OS)
• IBM (OS/2, AIX, OS/400, OS/390, VM/CMS, DOS/VSE, DOS/360, OS/360, MFT, MVT, PC-DOS, SVS, MVS, TPF, ALCS, z/OS)
• ICL (EXEC, JEAN, MINIMOP, GEORGE,KOZBER MANUL)
• Microsoft (MS-DOS,PC-DOS, DR-DOS, FreeDOS, DOS, QDOS, Microsoft Windows: 1.0, 2.0, 3.x, 95/98/Me, CE i Mobile, NT/2000/XP/2003/FLP/Vista/2008/7/8, PetrOS, ReactOS)
• Novell (Novell NetWare, Novell DOS)
• NeXT / NeXTStep
• Unisys ( MCP(Master Control Program), OS 2200)
• UNIX ( AIX, Android, BSD, FreeBSD, NetBSD, OpenBSD, DragonFly BSD, DesktopBSD, PC-BSD, bada, Darwin, Digital UNIX, HP-UX, iOS)
• IRIX, OS X, Minix, OSF/1, SCO UNIX, Oracle Solaris (dawniej Sun Solaris, SunOS), Oracle OpenSolaris, OpenIndiana, Unix Wersja 7, QNX, Ultrix, Venix, Xenix, GNU/Linux,GNU/Hurd, Linux, Palm webOS
• Real Time OS (LynxOS, FlexOS, OS9, Phoenix-RTOS, QNX, Nut/OS, RT-Linux, VxWorks, Suse Linux Enterprise Real Time, MicroC/OS-II)
• Inne ( Agnix, Amoeba, AtariDOS, AtheOS/Syllable, Athene, Azure Operating System, Commodore DOS (zapisany w stacji dysków), Contiki, CP/J, CP/M, CROOK, eComStation, Egzekutor RTX, EMOS, EPOC32, GEM, GEOS, Inferno, IOS, iRMX, ISIS-II, Kylin, MenuetOS, Mikros, Multics, Palm OS, Quarn OS, SkyOS, Symbian, UDOS, Unununium, System V7)

Dotyczy to dowolnego sprzętu komputerowego, mikroprocesorów lub nawet mikrokontrolerów jednoukładowych 8-bitowych, 16, 32 bitowych.
Podstawową strukturą szablonu dla tworzenia oprogramowania dla sterowników są struktury zawierające statusy każdego typu sterownika eHouse1 w zależności od typu architektury

• RS-485 (Magistrala szeregowa przemysłowa)
• Ethernet (LAN)
• CAN (Controller Area Network)

oraz rodzaju sterownika np.

• RoomManager
• HeatManager
• ExternalManager
• CommManager
• LevelManager

Bez względu na medium transmisyjne i protokół transmisji:

• RS-485 „Uart” eHouse 1
• TCP/IP – Ethernet eHouse, eHouse4Can
• UDP – Ethernet eHouse, eHouse4Can
• Inne media transmisyjne

Pozwalają one na bezpośredni odbiór ramki zawierającej status danego typu sterownika i załadowanie go do struktury danych dla danego sterownika – bezpośrednie przekopiowanie bufora pamięci bez dekodowania informacji.
Struktury umożliwiają automatyczne dekodowanie odebranej ramki transmisyjnej i przyporządkowanie do zmiennych struktury wliczając zmienne bitowe.
Definicja Unii zawierających struktury poszczególnych sterowników pozwala na przekopiowanie bufora pamięci odebranej ramki i załadowanie do elementu unii „data”. Dzięki czemu zapis ramki jest natychmiastowy, a w momencie odczytania elementów struktury następuje „automatyczne dekodowanie” informacji zawartych w strukturze.

Uwaga: zdefiniowane unie zawierające stan sterowników eHouse1 wymagają przekopiowania z przesunięciem (offsetem):
1 – dla wybranego normalnego adresu, Ramka: {size}[ehouse1status struktura]
3 – dla wybranego rozszerzonego adresu (przy przesyłaniu także adresu własnego sterownika), Ramka: {size}{to addrh}{to adrl}[ehouse1status struktura]
– Struktura ma postać: {AddrH}{AddrL}{’s’}[Dane……………..]
gdzie: AddrH – Adres – MSB
AddrL – Adres – LSB
's’ – litera s oznaczająca STATUS jako typ przesyłanych danych

Inteligentny Dom eHouse – programowanie C struktury sterowników eHouse 1

Struktury są częścią wspólną dla każdej aplikacji dla dowolnego mikroprocesora czy systemu operacyjnego.
Odbiór statusu, puźniejsze przetwarzanie, akwizycja danych, wyświetlanie wymaga już tworzenia indywidualnego oprogramowania na daną platformę sprzętową i softwarową.
Pola unii wpisuje się po znaku „.” jeśli nie mamy do czynienia ze wskaźnikiem lub „->” jeśli jest to wskaźnik. np. „HM.AddrH” lub *(HM->AddrH)

Opis oprogramowania integrującego system eHouse z zewnętrznym oprogramowaniem i sprzętem:

• Napisać funkcję odbioru ramki statusu dla indywidualnej platformy sprzętowej i softwarowej
• Utworzyć tablicę instancje unii w ilości >= od ilości sterowników sprzętowych eHouse 1:
  RMeHouse1Status RMs[COUNT_OF_RMS]; //Dla roommanagerów w ilości = COUNT_OF_RMS dla PC może to być do 250
  //dla innego typu urządzenia jak najmniejsza ilość aby nie obciążać systemu np kilka sztuk więcej niż liczba sterowników
  HMeHouse1Status HM; ///Jedna instancja heatmanagera jeśli jest w systemie
• zainicjować wszystkie elementy unii RMs[i].AddrH=55; oraz RMs[i].AddrL=%x% wartościami adresów zainstalowanych sterowników RoomManager’ów
• jeśli posiadamy HeatManager zainicjować „HM.AddrH=1;” oraz „HM.AddrL=1;” – jest to stały adres HeatManager’a
• przy odbiorze ramki statusu z dowolnego media transmisyjnego porównać pole AddrH i AddrL bieżącej ramki i przekopiować do instancji unii o tym samym adresie np funkcją memcpy zgodnie z algorytmem
  for (k=0;k
  np w zależności od definicji funkcji memcopy dla danego kompilatora i systemu:
  memcpy(*RMs[i]->data,*(ReceivedBuffer+offset),sizeof(RMs[i])) gdzie „i” jest indexem RoomManagera ze zgodnym adresem w stosunku do odebranej ramki
• W tym momencie otrzymujemy szablon aplikacji na dowolny system zawierający w strukturze dla sterownika zdekodowany ostatni status dla każdego sterownika
• W oparciu o te dane możemy tworzyć online’owe bramki komunikacyjne, analizatory logów, aplikacje przetwarzające zaawansowane algorytmy automatyki zależne od wielu parametrów

Szablon aplikacji jest na tyle prosty i wydajny że przy pomocy mikrokontrolera 8 bitowego można przetwarzać te dane w czasie rzeczywistym.

przykład zaawansowanego algorytmu obrazujący użycie unii ze statusami po automatycznym ładowaniu danych:

if (
(RMs[0].OUT.o1) && //jeśli wyjście 1 RM[0] włączone
(RMs[1].INPUTS.i7) && //i jeśli wejście 7 RM[1] włączone
(!RMs[2].INPUTS.i3) && //i jeśli wejście 3 RM[2] wyłączone
(!RMs[11].OUT.o7) && //i jeśli wyjście 7 RM[11] wyłączone
(RMs[4].ADC.an1<255) //i jeśli wartość pomiaru przetwornika analogowo cyfrowego an1 wymaga przeliczenia z wartości

) //zaawansowany warunek
if (!RMs[7].OUT.o13) tylko jeśli wyjście 13 RM[7] wyłączone
{ //uruchom zdarzenie – włącz wyjście 13 RMs[7]
SendEvent(„5507210d010000000000”);//uruchomienie – przesłanie zdarzenia „direct event” w kodzie hex
// hhlleea1a2a3a4a5a6a7
//gdzie
// hh – AddrH
// ll – AddrL
// ee – Event Code (command)
// a1..a7 – (argumenty dla komeendy)
}