Skill do alexa

Szukamy osoby która napisała by dla nas skill-a do alexy. Posiadamy system automatyki który działa o sterownik i moduły I/O. Sterownik to urządzenie które oprócz portów I/O wyposażony jest w port TCP/IP. Na dzień dzisiejszy urządzenie obsługuje dwa standardy komunikacji zewnętrznej pierwszy to MODBUS-IP drugi to GENERIC-IP protokół oparty o warstwę TCP/IP w której sterowanie odbywa się szesnastkowo a odpowiedź w asci. Komunikacja z ALEX-a mogła by być po MQTT lub po czymś innym tak aby było to stabilne. Tematy które muszą zostać rozwiązane to budowa dynamicznego skill-a. Nasz system to różnego rodzaju moduły rozszerzeń I/O podpinane do jednego sterownika ale protokół sterowania i feedback-u niezależnie od urządzenia mamy ustandaryzowany. Na dzień dzisiejszy sterownik obsługuje do 32 modułów rozszerzenia I/O. Ale dla tego projektu ilość ta może zostać zmodyfikowana. Każdy moduł może mieć maksymalnie 16 wejść których stan jest przekazywany na 2 bajtach 16 wyjść których stan jest przekazywanych na 2 bajtach i dwa wejścia czujników których stan jest przekazywany również na 2 bajtach. Muszę tu jednak zaznaczyć, że urządzenie które teraz posiadamy ma maksymalnie 10 wyjść fizyczny i 6 wyjść wirtualnych oraz 6 wejść fizyczny. Myślimy o urządzeniach do alex-a które będą miały maksymalnie 6 wejść i wyjść fizycznych. Nie mamy zbyt dużego doświadczenia w zakresie napisania takiego driver-a ale robiliśmy testy na driver-ze HUE podszywając się pod ich strukturę i wygląda to obiecująco. To co jest innego u nas to wiele urządzeń rozszerzenia w ramach jednego sterownika i wiele wejść i wyjść. Pomysły są dwa - pierwszy driver to driver wirtualny na naszym sterowniku który zakładają, że ograniczymy ilość wyjść w każdym urządzeniu do 6 i ilość urządzeń do 32 w ramach jednego sterownika to mamy 192 wyjścia do zwizualizowania po stronie alex-a. Rozważamy coś takiego aby ograniczyć wymianę informacji z chmurą dla ALEX-a do 128 wyjść, 64 scen i 16 stref grzewczych. Pytanie czy skill może być tak zbudowany, że jeżeli użytkownik wykorzystuje tylko część wyjść do sterowania dostępnych w interfejsie konfiguracyjnym to czy te i tylko te wyjścia mogą mu się wyświetlić w aplikacji sterującej ALEX-a tak aby nie dostawał tych które nie są wykorzystane. Szukamy również rozwiązania na połączenie komend głosowych w ramach naszego programu konfiguracyjnego. Efektem pracy ma być rozwiązanie w którym to Klient kupuje urządzenia KOHER podłącza je i konfiguruje narzędziem konfiguracyjnym KOHER-BINDER następnie podłącza głośnik ALEX-a w miejscu instalacji urządzeń, zakłada konto dla ALEXA dodaje skill-a KOHER który wyświetla mu listę przycisków, stref i scen skonfigurowanych w oprogramowaniu KOHER-BINDER. Głośnik ALEX-a ma również realizować funkcję sterowania głosowego dla wyjść i komend wybranych w oprogramowaniu konfiguracyjnym KOHER-BINDER. Oczywiście jesteśmy otwarci na wszystkie pomysły i sugestie.