Elektroda.pl
Elektroda.pl
X
Elektroda.pl
Licencja Pulsonix
Proszę, dodaj wyjątek dla www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Sterownik pomp Grundfos Alpha

tmf 03 Maj 2019 12:43 2970 29
  • Sterownik pomp Grundfos Alpha
    Chciałbym przedstawić w sumie bardzo prosty projekt – układu pośredniczącego pomiędzy nowymi pompami Grundfos Alpha, a sterownikiem ogrzewania. Kilka lat temu prezentowałem układ sterownika kotłowni, który ma możliwość sterowania pompami Grundfos UPE z użyciem protokołu GeniBus. Niestety pompy te mają taką sobie elektronikę – w trakcie tych kilku lat użytkowania na 5 pomp padły mi 3. Grundfos też się wycofał z ich sprzedaży i powstał problem – mam sterownik, który może sterować innymi pompami, ale tylko w trybie on/off, bez informacji zwrotnej o ewentualnej awarii.
    W ciągu tych lat, zmieniła się też koncepcja sterowania urządzeniami – co raz częściej wykorzystuje się do sterowania urządzeniami grzewczymi prosty sygnał PWM. W stosunku do skomplikowanych protokołów typu GeniBus ma to pewne zalety: przede wszystkim prostota układu i implementacji. Oczywiście ilość informacji jaką możemy przesłać do pompy, lub z niej odczytać dzięki PWM też jest ograniczona, ale podstawowe rzeczy, typu sterowanie przepływem, uśpienie pompy, informacje o przepływie lub poborze energii i ewentualnej awarii, możemy bez problemu uzyskać. Niestety mój moduł sterowania kotłownią nie ma możliwości generowania przebiegów PWM o wymaganej przez Grundfosa charakterystyce, ani tym bardziej nie ma możliwości ich odczytywania. Powstał więc dylemat – zaprojektować nowy układ, lub go protezować. Wybrałem to drugie – proteza umożliwiająca sterowanie maksymalnie 5 pompami Grundfos (lub innymi, sterowalnymi przez PWM). Ograniczenie do 5 pomp wynika głównie z powodu ilości koniecznych złącz śrubowych – trzeba by użyć bardzo dużych obudów na szynę DIN, co po prostu nie ma większego sensu, bo w większości domowych kotłowni więcej pomp nie potrzebujemy. A jeśli ktoś potrzebuje to może zrobić dwa takie moduły.
    Prezentowany układ jest banalnie prosty – 8 bitowy mikrokontroler XMEGA32E5, sprzętowo generujący 5 przebiegów PWM (można więcej, ale u mnie nie ma takiej potrzeby), oraz odczytujący stan 5 wejść PWM. Układ załatwia interfejs pompa-procesor, dodatkowo mamy możliwość sterowania pompami z zewnątrz przez interfejs RS485 lub RS232 (ten ostatni dodałem tylko jako prosty interfejs serwisowy, do podglądu co się dzieje w razie awarii i sterowania przy pomocy poleceń tekstowych, w formie zrozumiałej dla człowieka).
    Przez interfejs RS485 możemy w pełni sterować podłączonymi pompami (ustawienie mocy, odczytanie diagnostyki), a także interfejsem sygnalizującym pracę układu. Można też przez ten interfejs uaktualnić software – wykorzystując wbudowany bootloader. I tu właśnie leży wyjaśnienie zagadki dlaczego użyłem XMEGA32E5, zamiast odpowiednika z mniejszą ilością FLASH (program zajmuje około 11 kB i zmieściłby się w XMEGA16E5). Użyty protokół komunikacyjny – multimaster RS485, zajmuje około 3 kB FLASH i wraz z resztą kodu bootloadera (weryfikacja poprawności kodu aplikacji, autoryzacja) zajmuje dokładnie 4094 bajty FLASH. Ponieważ tylko XMEGA32E5 posiada bootloader o długości 4096 bajtów, więc nie mogłem użyć mniejszego procesora, co zresztą po porównaniu cen i tak nie miało większego sensu.
    Układ potrafi działać autonomicznie, ale większy sens jest, gdy jest sterowany przez mój sterownik kotłowni, który nadzoruje pracę pomp. Jak widać, całość mieści się w standardowej obudowie na szynę DIN, na górze mamy 6 LEDów dwukolorowych – 1 LED wskazuje włączenie układu (kolor zielony), oraz wejście w bootloader (kolor czerwony). Dodatkowo w przypadku, gdy nie zgadza się CRC32 kodu aplikacji, program wchodzi w bootloader oczekując na poprawny kod, co sygnalizuje okresowo migający LED.
    Pozostałych 5 LEDów sygnalizuje stan każdej z pomp. Kolor zielony – wszystko OK, kolor czerwony – błąd pompy. Dzięki temu użytkownik może się szybko zorientować, czy coś jest nie tak. Dodatkowo LEDy można wykorzystać do sterowania – jako przyciski dotykowe, jednak, póki układ jest sterowany przez sterownik zewnętrzny, ta funkcja jest nieużywana. LEDy dla zaoszczędzenia pinów IO są sterowane multipleksowo.
    Zasilanie
    Układ posiada przetwornicę impulsową, generującą 5V niezbędne dla generowanego sygnału PWM dla pomp, oraz stabilizator liniowy low-drop generujący z 5V 3,3V do zasilania procesora i transceivera RS485. Sam układ może być zasilany napięciem z zakresu 7-24V AC/DC, dodatkowo jest zabezpieczony bezpiecznikiem polimerowym.
    Sygnał PWM
    Pompy Grundfos wymagają sygnału sterującego PWM o f=100 do 4000 Hz (mój układ generuje 1 kHz), o napięciu z zakresu 4-24V – stąd w układzie stabilizator na 5V. Działanie pompy zależy od wypełnienia PWM. Ponieważ sygnał trafiający do pompy trafia na LED transoptora, więc całość jest optoizolowana w pompie, zrezygnowałem więc z dodatkowej optoizolacji w układzie. Podobnie optoizolowany w pompie jest zwrotny sygnał PWM. Ponieważ sygnał trafia na LED, sterowanie tak naprawdę jest prądowe, a nie napięciowe – daje to dużą odporność na zakłócenia.
    Interpretacja sygnału PWM przez pompę zależy od wybranego profilu. Zazwyczaj brak PWM powoduje jej pracę zgodnie z parametrami ustawionymi przy pomocy przycisków na pompie. Zgodnie z notą pompa interpretuje sygnał następująco (profil A):
    ≤ 10% – maksymalna moc,
    > 10% – ≤ 84% – moc proporcjonalna do wypełnienia,
    > 84% – ≤ 91% – minimalna moc,
    > 91% – ≤ 95% – histereza on/off,
    >90% - tryb standby.
    Jest jeszcze profil C, w którym podane wartości są odwrotne – dla bezpieczeństwa przy stosowaniu w obiegach solarnych. Chodzi o to, aby przy rozłączeniu lub braku sygnału kontrolnego, pompa działała z maksymalną mocą, co zapobiega przegrzaniu instalacji solarnej.
    Pompa generuje zwrotnie sygnał PWM o f=75 Hz inforumujący o jej stanie:
    - 95% - pompa w trybie standby,
    - 90% - zablokowany rotor,
    - 85% - błąd elektryczny,
    - 75% - ostrzeżenie,
    - 0%-70% - moc wyjściowa.
    Program
    Jak pisałem, układ posiada bootloader, umożliwiający wczytywanie nowego wsadu poprzez RS485. Właściwa aplikacja kontroluje pompy, generując zadany przez sterownik sygnał PWM i sprawdzając zwrotnie stan pompy. Inne układy podłączone do magistrali mogą odczytywać bieżący stan pomp oraz go zmieniać. Jak widać nie jest to dużo, bo cała logika sterująca temperaturą i przepływami umieszczona jest w głównym sterowniku kotłowni (który zresztą wkrótce zmienię na coś nowszego). Sterownik może wysyłać powiadomienia do wybranych urządzeń o awarii pompy.
    Całość zabezpieczona jest CRC32 – po każdym restarcie układ sprawdza poprawność kodu aplikacji, oczywiście nad wszystkim czuwa WatchDog. W przypadku restartu do pamięci logowany jest powód – czy jest to zadziałanie WatchDoga, zanik zasilania, czy inne przyczyny. Jest to o tyle istotne, że zadziałanie Watch Doga może sygnalizować problem z aplikacją
    Komunikacja z otoczeniem odbywa się po magistrali RS485 – w tym celu stworzyłem protokół multimaster, ale o tym w przyszłości. Dzięki temu mogę łatwo wymieniać dane pomiędzy urządzeniami (elementami systemu Home Automation), mam też mostki – RS485-USB oraz RS485-radio (pokazywałem już na elektrodzie).
    Problemy
    W Eagle, w którym projektowałem PCB, są symbole tranzystorów SMD w obudowie SOT23 z wyprowadzeniami w formacie EBC i BEC. O ile te drugie można kupić, o tyle nie spotkałem się z dostępnym tranzystorem PNP z układem wyprowadzeń EBC. Na szczęście odwrócenie tranzystorów plecami w dół umożliwiło ich przylutowanie.
    Drugi mały błąd to brak rezystora ściągającego linię RE/DE transceivera RS485 do masy. Nie jest to wielki problem, ale taki rezystor zapobiega przypadkowemu włączeniu nadajnika, w trakcie włączania układu, lub, kiedy procesor nie steruje linią RE/DE (np. w czasie resetu). Nie przeszkadza to w normalnej pracy, tym bardziej, że sam protokół wymiany danych po RS485, którego używam sprawdza poprawność i w razie potrzeby dokonuje retransmisji ramki danych.
    Poza tym układ działa doskonale i robi to, co od niego oczekiwałem.
    Kilka przykładów
    Upload nowego firmware do jednego ze sterowników po magistrali RS485. Aplikacja do uploadowania jest napisana w Qt:
    Sterownik pomp Grundfos Alpha
    Możemy też przez interfejs RS485 wydawać inne polecenia w celu sprawdzenia bieżącego stanu układu, wersji oprogramowania itd. Urządzenia mogą przesyłać informacje po sieci w sposób w miarę przejrzysty dla człowieka.
    Realizacja prostych poleceń tekstowych umożliwia komunikację za pomocą dowolnego terminala, co dodatkowo uniezależnia cały system od bardziej skomplikowanego softu. W razie czego debuggowanie zapewne też będzie łatwiejsze. Poniżej przykład sprawdzenia wersji oprogramowania modułów, statystyk magistrali i typu modułu:
    Sterownik pomp Grundfos Alpha
    No i na koniec kilka zdjęć gotowego modułu:
    Sterownik pomp Grundfos Alpha Sterownik pomp Grundfos Alpha
    No i schemat oraz rysunek PCB:
    Sterownik pomp Grundfos Alpha Sterownik pomp Grundfos Alpha

    Fajne! Ranking DIY
    Potrafisz napisać podobny artykuł? Wyślij do mnie a otrzymasz kartę SD 64GB.
  • Licencja Pulsonix
  • #2
    Janusz_kk
    Poziom 20  
    Fajne, masz plusa, co prawda nie mam pomp grunfosa ale temat ciekawy, czy w celach dydaktycznych można zobaczyć źródła?
    szczególnie interesują mnie zabezpieczenia, czyli obsługa WG, crc i bootloader. Może być na priva tylko do mojej wiadomości.
  • #3
    onehour
    Poziom 9  
    Robiłem niedawno trochę podobny układ, ale do współpracy z pojedynczą pompą Grundfos UPM3, z wykorzystaniem klona Arduino Nano (ATmega328). Komunikacja była zrealizowana poprzez MODBUS RTU (warstwa fizyczna RS485). Do dekodowania PWM wykorzystałem INT0 i TC1 (16bitów), generowanie PWM sprzętowe to oczywiście sprawa banalna. W sumie docelowo układ miał być bardziej rozbudowany. Niestety z przyczyn obiektywnych projekt najpewniej nie zostanie dokończony.
    Bardzo mi się podoba projekt kolegi i w związku z tym mam pytania.
    Czy komunikacja poprzez RS485 bez izolacji galwanicznej w takim układzie nie sprawia problemów?
    Czy zdradzi kolega tajemnicę w jaki sposób zostało zrealizowane dekodowanie sygnału PWM z 5-ciu wejść?
  • #4
    tmf
    Moderator Mikrokontrolery Projektowanie
    onehour napisał:
    Czy komunikacja poprzez RS485 bez izolacji galwanicznej w takim układzie nie sprawia problemów?

    Bez problemów, RS485 toleruje napięcie wspólne do o ile pamiętam 12V. Poza tym układy na szynie mają wspólną masę, więc tym bardziej nie powinno być problemów. IMHO w znakomitej większości przypadków RS485 separacji nie wymaga.
    onehour napisał:
    Czy zdradzi kolega tajemnicę w jaki sposób zostało zrealizowane dekodowanie sygnału PWM z 5-ciu wejść?

    W XMEGA jest event system, z którego impulsy można podać na timer pracujący w trybie pomiaru okresu i szerokości impulsu (w tej rodzinie timer mierzy obie rzeczy na raz, co upraszcza pomiar wypełnienia PWM). Kanał event system można podpiąć pod dowolny pin IO, w programie jeden kanał jest "przepinany" na kolejne piny wejściowe PWM (dokładnie co dwa okresy sygnału wejściowego). Jeśli nie ma doprowadzonego PWM, to następuje przepełnienie timera, co zgłasza przerwanie, w którym zapisywany jest błąd.
    Janusz_kk napisał:
    szczególnie interesują mnie zabezpieczenia, czyli obsługa WG, crc i bootloader.

    W wolnej chwili wrzucę odpowiednie części kodu. WD jest odpalony bez możliwości blokady na stałe (fusebity). W programie, bootloadera w jednym miejscu jest wykonywany reset WD. Kod aplikacji musi o to też zadbać, w przeciwnym przypadku reset procka - bootloader sprawdza CRC aplikacji (jest ono umieszczone w jej kodzie, automatycznie przez srec, po kompilacji). Jeśli CRC32 jest ok, to odpalana jest aplikacja ponownie, jeśli nie to bootloader czeka na nowy wsad. Dodatkowo użytkownik może wysłać polecenie wejścia bootloader - aplikacja softwarowo resetuje procka, co startuje bootloader, który czeka prze 1s na potwierdzenie wejścia w bootloader. Jeśli je otrzyma to czeka na nowy wsad, jeśli nie to startuje dotychczasową aplikację.
  • #5
    paluszasty
    Poziom 24  
    Jak zawsze w przypadku kolegi tmf dopracowany projekt.

    Czy mógł byś napisać coś o tym protokole GeniBus.

    Czy opłacało się robić przetwornicę "na piechotę" gdzie układ LM2675 kosztuje około 25-30zł. W tej cenie na pewno kupi się gotową zgrabną małą przetwornicę.
  • #6
    tmf
    Moderator Mikrokontrolery Projektowanie
    paluszasty napisał:
    Czy mógł byś napisać coś o tym protokole GeniBus.

    To protokół używany przez pompy Grundfosa, obecnie tylko duże pompy, nie do instalacji domowych. Kiedys mieli pompy UPE, z którymi można było się komunikować przez GeniBUS. Dawno temu wrzuciłem na elektrodę materiały na ten temat. Można było przez niego ustawiać profil pompy, odczytywać temperaturę czynnika, moc, błędy, przepływ itd.
    paluszasty napisał:
    Czy opłacało się robić przetwornicę "na piechotę" gdzie układ LM2675 kosztuje około 25-30zł. W tej cenie na pewno kupi się gotową zgrabną małą przetwornicę.

    Nie rozpatrywałem tego w tych kategoriach. LM2675 jest relatywnie drogi, ale miałem na stanie jeszcze zapasy do zużycia. Jest wiele tańszych przetwornic, które można użyć. Ta przetwornica ma tą zaletę, że może pracować z napięciem na wejściu 24VAC (typowe w automatyce), czyli po wyprostoawaniu ponad 33VDC. (dopuszczalne to 40V). U mnie w systemie mam napięcie 24VAC, do zasilania m.in. elektrozaworów i regulatorów w CO.
  • Licencja Pulsonix
  • #7
    And!
    Admin grupy Projektowanie
    Co do ankiety, w systemie HA interesowałoby mnie:
    1. wykorzystanie komponentów różnych producentów, oraz własnych modułów, czyli takie rozwiązanie integrujące różne rozwiązania
    2. opracowanie własnych bezprzewodowych, energooszczędnych, tanich modułów które rozrzucone w różnych miejscach domu poinformują o problemie (np. zalanie na strychu, lub zbyt długo otwarte okno dachowe itp.)
    3. uproszczenie modułów z pkt. 2 jako tylko raportujące zdarzenia i stan baterii (komunikacja jednokierunkowa), jak zapewnić to aby ograniczyć jednoczesne nadawanie raportów przez kilka modułów
    4. zbadanie możliwości wykorzystania tanich modułów RF OOK + np. kodowanie np. manchester oraz ramka danych z możliwością korekcji błędów czy to zapewni lepszą niezawodność transmisji
    5. odbiorniki/nadajniki "bazowe" dla modułów RF systemu rozproszone na większych obiektach i połączone do systemu po magistrali RS485, Ethernet lub WiFi, w efekcie ramka z bezprzewodowego modułu może zostać odebrana przez jedną ze "stacji bazowych" lub przez kilka a następnie trafia do sterownika, tak samo z nadawaniem, można wysłać komendę sekwencyjnie przez transceiver na każdym piętrze
  • #8
    tmf
    Moderator Mikrokontrolery Projektowanie
    Punkty 2-5 są proste do zrealizowania, właściwie gotowe kody już mam. Przy czym radio w HA traktuję raczej jako ciekawostkę. IMHO problem tkwi w niezawodności takiego rozwiązania, prostocie konfiguracji oraz bateriach. Nawet jeśli przyjdzie nam wymieniać baterię co kilka lat, to i tak, przy ilości urządzeń jakie mamy w domu, które są składnikami tego systemu, praktycznie ciągle jakieś będzie wymagało serwisu :) Jako opcja w starych budynach bez odpowiedniej infrastruktury to ok, w nowych IMHO prościej pociągnąć kabel.
    Ja to rozwiązałem tak, że mam kable, jednak jest też mostek RS485-radio, więc nie ma problemu z podpięciem urządzenia radiowego. Fajne są moduły RFMxxx, tanie, energooszczędne, wiele z nich ma sprzętowe ułatwienia w transmisji danych. Ja używam RFM22 (bo tworzyłem to wiele lat temu) i jestem z nich zadowolony.
    Co do punktu 1 - to głównym problemem jest dostęp do informacji technicznych. Zresztą, przy cenie gotowców, to chyba jeśli ktoś się na nie decyduje, to prościej cały system na tym postawić, niż kombinować.
  • #9
    And!
    Admin grupy Projektowanie
    Co do 1. czasami jest to opłacalne jeżeli jest gotowy moduł w przystępnej cenie lub estetycznej obudowie (np. naścienny czujnik temp/wilgotności itp.) ew. urządzenie mechaniczne (np. radiowy sterownik głowicy termostatycznej w grzejniku).

    Co do dostosowywania się do urządzeń RF jest dość rozbudowany "translator" RFLink http://www.rflink.nl/blog2/ ale niestety wygląda na zamknięty kod,
    oraz narzędzie Universal Radio Hacker https://github.com/jopohl/urh
    URH może się przydać także przy debugowaniu uruchamiania swoich urządzeń RF.
  • #10
    Slawek K.
    Poziom 30  
    Kolego @tmf , bardzo fajny projekt.
    Czy byłbyś uprzejmy dać link do tej obudowy ? Projektuję aktualnie płytkę MPPT i wcisnąłbym go chętnie do takiej obudowy.

    Pozdr
  • #11
    tmf
    Moderator Mikrokontrolery Projektowanie
    Slawek K. napisał:
    Czy byłbyś uprzejmy dać link do tej obudowy ?

    Kupiona w TME obudowa na szynę DIN. Niestety TME nie trzyma zbyt długo historii zamówień i dokładnego kodu ci nie podam.
  • #13
    Linoge
    Poziom 26  
    Z innej beczki gdzie można kupić wtyczki do wejścia sterowania tymi pompami ?
  • #14
    tmf
    Moderator Mikrokontrolery Projektowanie
    Linoge napisał:
    Z innej beczki gdzie można kupić wtyczki do wejścia sterowania tymi pompami ?

    Są gotowe kable z takimi wtyczkami, np. na niektórych portalach aukcyjnych. Samych wtyczek nie widziałem, ale są standardowe, po prostu nie widziałem u polskich dystrybutorów, lub źle szukam. Jeśli nie jest potrzebna wodoszczelność to pasują Molexy - tam jest rozstęp pinów o ile pamiętam 2,54mm, czyli standardowy.
  • #15
    Erbit
    Poziom 33  
    Co do ankiety - głosowałem na "Pomysł bez sensu, bo jest pełno tego typu systemów").
    Nie sądzę by społeczność elektrody była większą społecznością od tych najbardziej znanych (choćby Domoticz).

    And! napisał:
    Co do ankiety, w systemie HA interesowałoby mnie:
    ...


    Większość tych punktów Domoticz obejmuje (inne systemy pewno też).

    Nie wiem czy Domoticz (lub inne) posiadają zrealizowany punkt 5. Ja korzystam z systemu firmowego, który posiada taki system i wiem, że nawet w małych obiektach czasem są miejsca, do których radiowo ciężko się dociera, więc myślę, że w innych HA też takie problemy występują i jakieś rozwiązania na to są.
  • #16
    tmf
    Moderator Mikrokontrolery Projektowanie
    Erbit napisał:
    Co do ankiety - głosowałem na "Pomysł bez sensu, bo jest pełno tego typu systemów").
    Nie sądzę by społeczność elektrody była większą społecznością od tych najbardziej znanych (choćby Domoticz).

    Społeczność Windowsa jest jeszcze większa, ale nie wpływa to istotnie na jego rozwój, bo większość to bierni użytkownicy.
    Tak samo myślę, że jest w przypadku Domoticza - wiele osób korzysta, bardzo niewielu wnosi coś do projektu - stąd ankieta. Chciałbym wiedzieć, ile osób chciałoby aktywnie uczestniczyć w takim projekcie i może wnieść jakąś wiedzę. I jak widać nie jest ich mało.
    Poza tym Domoticz, to tylko oprogramowanie integrujące. A trzeba elektroniki, żeby to działało. Większość elektroniki sterującej jest banalnie prosta, ale kosztuje krocie. I tu właśnie jest pole do popisu. Zebrać w jednym miejscu różne realizacje, wspólnie je poprawić i zrobić sterowniki przewyższające, albo przynajmniej dorównujące jakością tym firmowym, tyle, że niskim kosztem. Idea HA w którym jest centralne zarządzanie też mi się nie podoba, bo w razie padu mamy kłopot. Osobiście uważam, że każdy sterownik powinien w maksymalnym stopniu automatyzować swoje działania, a centralny system sterujący powinien służyć wyłącznie do wygodnego zarządzania i podglądu całości. Dlatego nie myślę o rozwiązaniu konkurencyjnym, czy stworzeniu od nowa czegoś w stylu Domoticza, wręcz przeciwnie, taki system można by do Domoticza podpiąć. Fajnie by było mieć także projekt open-hardware z gotowymi modułami do samodzielnego wykonania.
  • #17
    Erbit
    Poziom 33  
    tmf napisał:
    ...
    Społeczność Windowsa jest jeszcze większa, ale nie wpływa to istotnie na jego rozwój, bo większość to bierni użytkownicy.
    ...


    To akurat zły przykład ale rozumiem co chciałeś wyrazić.


    tmf napisał:
    ... Większość elektroniki sterującej jest banalnie prosta, ale kosztuje krocie. I tu właśnie jest pole do popisu.

    To fakt choć coraz częściej ta elektronika jest coraz tańsza - choćby Sonoff (który de facto można przeprogramować).

    tmf napisał:
    ... Idea HA w którym jest centralne zarządzanie też mi się nie podoba, bo w razie padu mamy kłopot....

    Posiadam HA, który pozwala na "połączenie jego elementów pomiędzy sobą z pominięciem centrali". To powoduje, że większość połączeń (np. włącznik na ścianie, pilot czy inny przycisk połączony ze sterownik oświetlenia) jest niezależna od centrali. To bardzo ciekawe rozwiązanie podnoszące bezpieczeństwo funkcjonalne systemu.
    Niestety nie wszystko da się zrealizować za pomocą "połączeń bezpośrednich pomiędzy elementami" a wtedy trzeba podpierać się centralą.

    Kolejny problem (o którym kolega And! wspomniał) to zasięg radiowy. W moim systemie są dodatkowe bramki instalowane w sieci LAN (TCP/IP), do których można przypisać poszczególne urządzenia.

    Pozostaje jeszcze kwestia częstotliwości radiowej. Uważam, że ze względu na możliwe zakłócenia, tak popularne częstotliwości jak Wi-Fi czy 433 MHz nie wchodzi w grę. Pozostaje chyba jedynie 868 MHz ze swoimi ograniczeniami do nadawania 1% w czasie godziny - wtedy ma to prawo działać (to tak w ogromnym skrócie).

    [edyta]
    Widząc ogrom problemów, z którymi zetknął się producent mojego HA (a to co obserwuję to pewno wierzchołek góry lodowej) twierdzę, że poświęcanie czasu na takie rozwiązanie nie komercyjne nie ma większego sensu. Ilość problemów będzie rosła i nie będzie komu ich rozwiązywać. Powyżej podałem dwa przykłady *częstotliwość" oraz "połączenia bezpośrednie", które już same w sobie wymagają sporego zaangażowania w projekt. To nie zwykły przełącznik on/off a elektronika + oprogramowanie układowe w tej elektronice, że o jakiejś centrali i większym programie nie wspomnę.
  • #18
    tmf
    Moderator Mikrokontrolery Projektowanie
    Ogólnie nie jestem przekonany do połączeń radiowych, dlatego np. prezentowany moduł działa na RS485. Ale nic nie stoi na przeszkodzie, aby zrobić bramkę WiFi, albo moduł 868MHz<->RS485. Takie moduły też zrobiłem, dzięki czemu np. można gdzieś dać czujnik temperatury, dla którego połączenia kablowe ograniczałoby lokalizację i w efekcie nie mierzyło wiarygodnie temperatury.
    Erbit napisał:
    tmf napisał:
    ... Większość elektroniki sterującej jest banalnie prosta, ale kosztuje krocie. I tu właśnie jest pole do popisu.


    To fakt choć coraz częściej ta elektronika jest coraz tańsza - choćby Sonoff (który de facto można przeprogramować).

    To prawda, jest co raz więcej fajnych modułów, ale zwykle są to proste rzeczy, które można jako DIY wykonać bez problemów. Natomiast sterowników typu: sterownik ogrzewania, nawadniania, itp. już się nie uświadczy. A jak są to ceny zaporowe lub ograniczone możliwości integracji, bo wszelkie protokoły są utajnione :)
    Stąd idea zrobienia takiego systemu naprawdę open source/open hardware, a nie tylko protezy umożliwiającej podłączenie kilku komercyjnych systemów. Na elektrodzie mamy sporą społęczność i wielu zdolnych ludzi. Są lepsi hardwarowcy i softwarowcy, gdyby połączyć siły to możnaby stworzyć coś naprawdę fajnego. Pytanie, czy potrafimy współpracować?
  • #19
    Erbit
    Poziom 33  
    tmf napisał:
    ... Natomiast sterowników typu: sterownik ogrzewania, nawadniania, itp. już się nie uświadczy.

    Rozumiem, że naoisałeś o formie DIY (bo firmowe istnieją).

    Otóż nie do końca się i z tym zgodzę. System nawadniania DIY to prosta sprawa. Elektrozawór, transformator, systemowy on/off no i centrala, w której to odpowiednio zaprogramujesz.

    U mnie wygląda to tak:
    - kawałek szklarni z oświetleniem i dwoma przekaźnikami (lewa i prawa strona podlewania kropelkowego)
    Sterownik pomp Grundfos Alpha
    - przykładowy punkt pomiaru wilgotności gleby.
    Sterownik pomp Grundfos Alpha

    Reszta to program w centrali, który uwzględnia prognozę pogody np. gdyby miało padać co można ocenić po zmianie ciśnienia i wilgotności - to system nie podlewa ogrodu.

    Czujnik wilgotności to DIY (przypięty w centrali i widoczny przez nią jak oryginalny element), zaś elementy włączające elektrozawory to oryginalne włączniki on/off i tu DIY nie jest potrzebne.

    Sterowanie ogrzewaniem w formie DIY łatwe byłoby dla rozdzielaczy. Przy grzejnikach tradycyjnych już nieco trudniej. Moje (firmowe) na bateriach 2*AA wytrzymują od 1 do 1,5 roku (głowice z wyświetlaczem). Sądzę, że skonstruowanie DIY z takim wynikiem wcale nie będzie proste. Na dokładkę wystarczy otworzyć pierszwą lepszą głowicę elektroniczną by zobaczyć układ mechaniczny składający się z wielu przekładni - nie sądzę by udało się to wydrukować na drukarce 3D. Do tego harmonogram (nie w centrali a w głowicy), wykrywanie otwarcia okna, rożne tryby ogrzewania, etc. ... i do tego miniaturyzacja. Trochę w to nie wierzę - tym bardziej, że projekt (jak rozumiem) nie komercyjny.

    [edyta]
    Rozsądniejsze byłoby pójść pomysłem kolegi And! i dokonać integracji istniejących elementów. Do tego można by budować własne elementy ale tam gdzie to ma sens (np. uważam, że budowanie własnych głowic do CO nie ma sensu).

    Oczywiście z taką integracją wiążą się dodatkowe problemy (jak dokumentacja producentów, zmiany w dokumentacji a więc i aktualizacje w Waszym sofcie). Po drugiej stronie tego problemu leży ograniczenie funkcjonalności danego elementu. Więc albo ktoś będzie siedział i klepał kod do aktualizacji albo... nie wykorzystacie pełnej funkcjonalności obcego elementu.

    Na koniec pamiętaj, że pewno każdy z nas złożyłby sobie sam takie HA dla własnych potrzeb. Jednak gdybyśmy mieli zbudować go wspólnie to okazałoby się, że każdy z nas ma de facto zupełnie inne potrzeby i to przy tych samych elementach wykonawczych.

    Dodano po 26 [minuty]:

    tmf napisał:
    Ogólnie nie jestem przekonany do połączeń radiowych...


    Ja także - ale napisz - chcesz remontować dom przy instalacji HA lub jego rozbudowie ? ;)
    Na przewodową instalację można sobie pozwolić przy nowym lub remontowanym budynku ale po czasie i tak chcesz coś uzupełnić w HA i co wtedy? Czekasz aż do następnego malowania?

    [edyta 3]
    Na koniec życzę Wam powodzenia. Jestem ciekaw efektów i z chęcią bym skorzystał z Waszego projektu gdyby nie fakt, że już posiadam HA. Sądzę, że pojawi się wielu użytkowników - o wiele więcej niż w ankiecie.
    Jeszcze raz powodzenia.
  • #20
    Janusz_kk
    Poziom 20  
    tmf napisał:
    Idea HA w którym jest centralne zarządzanie też mi się nie podoba, bo w razie padu mamy kłopot. Osobiście uważam, że każdy sterownik powinien w maksymalnym stopniu automatyzować swoje działania, a centralny system sterujący powinien służyć wyłącznie do wygodnego zarządzania i podglądu całości.

    Też o czymś podobnym myslę, ale autonomiczny sterownik to nadal unikalne urządzenie i innym się go nie zastąpi, do czego zmierzam, do sieci rozproszonych sterowników ale ze wspólnym programem, każdy sterownik "robi" tylko swoją część. Program byłby interpretowany na bieżąco coś jak basic w spectrumach, sterownik sam by go ściągał z sieci i go realizował, do nadzoru i sterowania byłby smartfon czy tablet. Sterowniki miałyby identyczny program i tylko nr w sieci by je identyfikował i określał role jakie pełnią, każdy rozgłaszałby swoje dane pomiarowe tak aby cała sieć miała aktualne dane, połączenie po rs485 + zasilanie np 12V, tam gdzie trzeba to dodatkowo sieć. To taki zarys propozycji, zaletą byłaby łatwa wymiana sterowników, byle tylko peryferia miał odpowiednie, to nadanie mu numeru i podłączenie do sieci.
    Może by wydzielić część tego tematu do nowego wątku?
  • #21
    Linoge
    Poziom 26  
    RS jest słabym pomysłem bo odległości mogą sięgać setek metrów. Topologia będzie pomieszana więc prędkość nie będzie oszałamiająca. Danych może nie będzie wiele a responsywność spada a czasami będzie wymagany update softu a to będzie trwało i trwało. To już lepszy się CAN wydaje.
    Wszystko to co napisałeś da się zrobić w domo. Wykonawcze node mcu a kolektorem danych jest domoticz. W espeasy możesz skrypty pisać. Nie zgodzę się z twierdzeniem iż domoticz jest gotowcem , którego się tylko konfiguruje ponieważ w większości wypadku trzeba jeszcze coś tam w nim grzebnąć. Co powoduje wykrywanie nowych bugów i ich rozwiązań. Co dla developera jest bezcenne, ponieważ pisanie softu to zazwyczaj tylko 20% czasu natomiast 80% czasu to testy.
    [edit]
    Wydaje mi się iż dużo większy sens miała być odpowiednia przystawka do RPI uzupełniająca jego możliwości. Czyli np.:
    - sensowne zasilanie z podtrzymaniem
    - bufory wejścia/wyjścia z możliwością podłączenia przekaźników
    - izolacja galwaniczna dla 1wire,i2c,Rs232,Rs485
    - przetworniki ADC
    - obudowa na szynę DIN.
    - skalowalność peryferiów
    - + wiele innych prostych usprawnień.
  • #22
    Erbit
    Poziom 33  
    Linoge napisał:
    ...Nie zgodzę się z twierdzeniem iż domoticz jest gotowcem , ...


    Jeśli w mojej wypowiedzi to wyczytałeś to nie taki był jej sens. Użyłem "gotowca" w znaczeniu czegoś co już istnieje, bez potrzeby pisania wszystkiego od podstaw.

    Wracając do tematu: wydaje mnie się, że gdybyście chcieli stworzyć urządzenia wykonawcze (jak twierdzicie tańsze i lepsze) i podłączyć je do istniejącego oporamowania (Domoticz czy jakiegokolwiek innego) to ma to sens. No... ale to tylko moje zdanie. Są też innych zdania.
  • #23
    Linoge
    Poziom 26  
    Raczej nie da zrobić się czegoś taniej niż 20 PLN jako urządzenie wykonawcze a tyle kosztuje sonoff basic.
  • #24
    tmf
    Moderator Mikrokontrolery Projektowanie
    Linoge napisał:
    RS jest słabym pomysłem bo odległości mogą sięgać setek metrów. Topologia będzie pomieszana więc prędkość nie będzie oszałamiająca. Danych może nie będzie wiele a responsywność spada a czasami będzie wymagany update softu a to będzie trwało i trwało. To już lepszy się CAN wydaje.

    Raczej nie masz racji. CAN to maksymalny transfer 1 Mb/s, przy czym trzeba uwzględnić propagację sygnału w medium, realnie taki transfer da sie uzyskać na max kilkanaście-kilkadziesiąt metrów. RS485 to transceivery nawet na 10 Mb/s, przy rozpiętości magistrali nawet 1200 m (przy odpowiednio mniejszej szybkości). Poza tym cena, prostota, to wszystko przemawia na korzyć rs485 w tym zastosowaniu.
    Linoge napisał:
    Wydaje mi się iż dużo większy sens miała być odpowiednia przystawka do RPI uzupełniająca jego możliwości. Czyli np.:
    - sensowne zasilanie z podtrzymaniem
    - bufory wejścia/wyjścia z możliwością podłączenia przekaźników
    - izolacja galwaniczna dla 1wire,i2c,Rs232,Rs485
    - przetworniki ADC
    - obudowa na szynę DIN.
    - skalowalność peryferiów
    - + wiele innych prostych usprawnień.

    Ja nie widzę większych zastosowań dla RPi - duże zużycie energii, OS, który może wprowadzić kłopoty ze stabilonością, itd. Jeśli już to jako miejsce agregacji danych, interfejs dla www, czy coś w tym stylu. Bezpośrednio do sterowania czymkolwiek takie platformy IMHO mają marginalny sens, skoro to samo uzyskam przy pomocy mikrokontrolera za 5 zł, który ma wszystkie niezbędne peryferia i zajmuje ułamek miejsca przeznaczonego na RPi + niezbędne dodatki.
    Erbit napisał:
    Otóż nie do końca się i z tym zgodzę. System nawadniania DIY to prosta sprawa. Elektrozawór, transformator, systemowy on/off no i centrala, w której to odpowiednio zaprogramujesz.

    U mnie wygląda to tak:
    - kawałek szklarni z oświetleniem i dwoma przekaźnikami (lewa i prawa strona podlewania kropelkowego)

    Masz rację, to proste. Stworzyłeś działający układ, wszystko ok. Pomyśl o ile fajniej byłoby mieć dostępny gotowiec, z gotowym softem, który tylko ew. uzupełniasz o potrzebne funkcje, zamiast budować wszystko od nowa? Dlatego właśnie uważam, że takie miejsce, w którym możnaby wspólnie coś zrobić byłoby fajne i ma to sens.
    Erbit napisał:
    Sterowanie ogrzewaniem w formie DIY łatwe byłoby dla rozdzielaczy. Przy grzejnikach tradycyjnych już nieco trudniej. Moje (firmowe) na bateriach 2*AA wytrzymują od 1 do 1,5 roku (głowice z wyświetlaczem). Sądzę, że skonstruowanie DIY z takim wynikiem wcale nie będzie proste. Na dokładkę wystarczy otworzyć pierszwą lepszą głowicę elektroniczną by zobaczyć układ mechaniczny składający się z wielu przekładni - nie sądzę by udało się to wydrukować na drukarce 3D. Do tego harmonogram (nie w centrali a w głowicy), wykrywanie otwarcia okna, rożne tryby ogrzewania, etc. ... i do tego miniaturyzacja. Trochę w to nie wierzę - tym bardziej, że projekt (jak rozumiem) nie komercyjny.

    Nic na siłę - oczywiście budowanie własnoręczne głowicy nie ma wielkiego sensu, skoro rozpracowane głowice są dostępne i można nimi sterować. Chociaż osoba doświadczona w druku 3D mogłaby pewnie z łatwością taką głowicę sobie zrobić. Ja np. mam system rozdzielaczowy, więc w kilku punktach steruję zaworami w szafce CO. I taki układ mam własnej konstrukcji, bo firmowe mnie nie zadowalały.
    Erbit napisał:
    Rozsądniejsze byłoby pójść pomysłem kolegi And! i dokonać integracji istniejących elementów. Do tego można by budować własne elementy ale tam gdzie to ma sens (np. uważam, że budowanie własnych głowic do CO nie ma sensu).

    Dokładnie tak.
    Erbit napisał:
    Ja także - ale napisz - chcesz remontować dom przy instalacji HA lub jego rozbudowie ? ;)
    Na przewodową instalację można sobie pozwolić przy nowym lub remontowanym budynku ale po czasie i tak chcesz coś uzupełnić w HA i co wtedy? Czekasz aż do następnego malowania?


    Tu nie widzę problemu. Przecież można zrobić mix różnych mediów transmisyjnych, użycie jako podstawy RS485 nie przesądza o braku możliwości użycia radia. Np. na dachu mam stację meteo zasilaną z solarów, która transmituje dane przez RFM22 do reszty systemu. I nie ma z ym problemu.
  • #25
    Erbit
    Poziom 33  
    tmf napisał:
    ...
    Stworzyłeś działający układ, wszystko ok. Pomyśl o ile fajniej byłoby mieć dostępny gotowiec, z gotowym softem, który tylko ew. uzupełniasz o potrzebne funkcje, zamiast budować wszystko od nowa? ...


    No... ale ja mam właśnie gotowy układ z softem, który pozwala mi zrobić z tym co zechcę ;)

    Myślę, że ten przykład (nawadniania) jest dobry by dostrzec jeszcze jedną rzecz. Otóż Ty zbudowałeś sobie sterowanie CO bo firmowe były dla Ciebie nieodpowiednie. Dla mnie także "gotowiec" jest nieodpowiedni (jeśli chodzi o system nawadniania), dlatego otwarty system dający możliwości poskładania z klocków i pełnego programowania to jest akurat coś dla mnie ale nie dla wszystkich podobnie jak Twój układ CO nie jest dla wszystkich.

    Obiecuję, że z zaciekawieniem będę śledził postępy ;)
    Powodzenia.
  • #26
    Linoge
    Poziom 26  
    @tmf Niepodważalną przewagą CAN jest arbitraż. Przy 100 elementach sieci policz sobie opóźnienia a nie jest to jakiś ogrom czujników. U siebie w domu mam obecnie ponad 60 różnych urządzeń (czujniki temperatury, elementy wykonawcze itd.- a to tylko płowa domu) Rs ma prędkość 1MB przy odległościach do 400 m. Potem niestety drastycznie spada. Podobnie dla CAN również znajdziesz drivery po 10Mb/s.
    Przyjmując prędkość 115200 / 11 boudów na bajt/20 bajtów w ramce/100 urządzeń . Przy pełnym wykorzystaniu pasma urządzenie dopcha się do magistrali 5 na sekundę, czyli realnie około 1-2 razy na sekundę!

    Jakie zużycie energii z 230V będzie miał Twój system ? Co z tego że urządzenia będą miały 1W skoro zasilacz konsumuje 2-5 razy tyle ?
    Skoro już przyznałeś że dane i tak przydało by się gdzieś kolekcjonować to co za różnica czy robi to RPi czy procek ?

    Niestety Twój system jest z góry przegrany ponieważ nie ma interfejsu bezprzewodowego bo jeśli do tego procka dodasz przetwornicę z 230V moduł wifi itd. to cena poszybuje w kosmos.
    Tak z ciekawości, bo sam zajmuję się stabilnością rozwiązań jak myślisz co jest bardziej stabilne procek z softem którego używa 1000 osób czy 100 000 RPi wyprodukowanych zgodnie z ISO w systemie testowanym przez miliony ? Wszystko ma swoje wady i zalety wybór zależy od aplikacji. Dodatkowym ograniczeniem Twojego rozwiązania będzie jego hermetyczność.
  • #27
    Erbit
    Poziom 33  
    Linoge napisał:
    ... U siebie w domu mam obecnie ponad 60 różnych urządzeń (czujniki temperatury, elementy wykonawcze itd.- a to tylko płowa domu) ...

    Nie chwal się, mam ponad 100 i niektóre przekazują więcej niż jedne parametr a to jeszcze nie cały dom.
    ;)

    Dlatego właśnie gdzieś na początku napisałem, że widzę z iloma problemami musiał zetknąć się producent choć zapewne to tylko wierzchołek góry lodowej.
  • #28
    Janusz_kk
    Poziom 20  
    Linoge napisał:
    Niepodważalną przewagą CAN jest arbitraż.

    Wcale nie musi być arbitraż, znam sieci urządzeń (ponad setka)
    które dużo więcej wymieniają danych bez arbitrażu i działają na RS485.
  • #29
    tmf
    Moderator Mikrokontrolery Projektowanie
    Linoge napisał:
    @tmf Niepodważalną przewagą CAN jest arbitraż. Przy 100 elementach sieci policz sobie opóźnienia a nie jest to jakiś ogrom czujników. U siebie w domu mam obecnie ponad 60 różnych urządzeń (czujniki temperatury, elementy wykonawcze itd.- a to tylko płowa domu) Rs ma prędkość 1MB przy odległościach do 400 m. Potem niestety drastycznie spada. Podobnie dla CAN również znajdziesz drivery po 10Mb/s.

    Obawiam się, że kompletnie się mylisz. CAN jest magistralą recesywną, w której jeden ze stanów powstaje pasywnie, a jeden aktywnie. Stąd czasy przejścia ze stanu recesywnego do aktywnego są krótkie, ale czasy przejścia ze stanu aktywnego do recesywnego zależą od obciążenia i pojemności magistrali. Stąd właśnie szybkość drastycznie spada wraz ze wzrostem odległości, w przeciwieństwie do RS485, w którym oba stany są aktywne, w efekcie pojemności magistrali mogą być szybciej przeładowywane. Stąd RS485 zawsze będzie działał szybciej, fizyki nie zmienisz. Nie ma to co prawda większego znaczenia, bo tego typu systemy nie transmitują duży ilości danych, a jeśli tak, to można wybrać zupełnie inne medium. Problem wielu urządzeń i latencji można łatwo rozwiązać wprowadzając switche i podziały na podsieci.

    Linoge napisał:
    Przyjmując prędkość 115200 / 11 boudów na bajt/20 bajtów w ramce/100 urządzeń . Przy pełnym wykorzystaniu pasma urządzenie dopcha się do magistrali 5 na sekundę, czyli realnie około 1-2 razy na sekundę!

    Coś ci szwankują obliczenia. Przy twoich założeniach mamy możliwość nadania 523 ramek/s, a więc urządzenie teoretycznie dopcha się co 2 ms. 100 urządzeń teoretycznie co 200 ms, ale i tak pod warunkiem zapewnienia arbitrażu w wyższych warstwach OSI, bo inaczej jedno urządzenie może przejąć magistralę i reszta nie dopcha się nigdy.. Te obliczenia dla CAN wypadają źle, bo musisz nadać bity synchronizujące (arbitraż) oraz end of frame i całą resztę mniej lub bardziej zbędnych informacji. Dla przykładu ramka dla RS485 tego nie wymaga, więc rzeczywista ilość przesłanych danych będzie większa, szczególniej jeśli pakiety są krótkie. Brak arbitrażu da się prosto rozwiązać, prawdopodobieństwo kolizji jest niskie dla rozsądnego obciążenia magistrali. Nie ma co zresztą wymyślać koła od nowa, algorytmy unikania kolizji są znane od dekad.
    Linoge napisał:
    Jakie zużycie energii z 230V będzie miał Twój system ? Co z tego że urządzenia będą miały 1W skoro zasilacz konsumuje 2-5 razy tyle ?

    Trudno się do tego odnieść, bo nie wiem o czym piszesz. Chyba na siłę starasz się coś udowodnić :)
    Linoge napisał:
    Niestety Twój system jest z góry przegrany ponieważ nie ma interfejsu bezprzewodowego bo jeśli do tego procka dodasz przetwornicę z 230V moduł wifi itd. to cena poszybuje w kosmos.

    Chyba się niezbyt orientujesz w temacie. Moduł WiFi to koszt ok. 1-2$.
    Linoge napisał:
    Tak z ciekawości, bo sam zajmuję się stabilnością rozwiązań jak myślisz co jest bardziej stabilne procek z softem którego używa 1000 osób czy 100 000 RPi wyprodukowanych zgodnie z ISO w systemie testowanym przez miliony ?

    Trochę argument typu, że miliony much nie mogą się mylić :) Nikt nie używa RPi w zastosowaniach przemysłowych, nie bardzo wiem jakie normy ISO RPi spełnia.
    Ponownie mam wrażenie, że nie rozumiesz problemu. Ja mam swój soft, który mogę łatwo przetestować bo jest prosty. Korzystając z PRi mam zabawkową platformę, na której działa mnóstwo softu, co do którego muszę wierzyć, że jest ok, ale wiemy, że nie jest + mój własny soft. Raczej nigdy 1 nie równa się 1+1. Chyba, że programujesz RPi jako bare metal...
  • #30
    Linoge
    Poziom 26  
    @tmf
    "Trochę argument typu, że miliony much nie mogą się mylić :) Nikt nie używa RPi w zastosowaniach przemysłowych, nie bardzo wiem jakie normy ISO RPi spełnia. "
    Wysyp SOMów jest ogromny co raz więcej jest właśnie adapterów do Pi. Mam na myśli normy choćby zarządzania jakością czyli między innymi projektem. W przemyśle norma. Wszystko musi mieć bloczki i być dobrze udokumentowane. Tutaj jak ktoś zrobi PCB i schemat to myśli że to jest dokumentacja. Tak wiem po co komu architektura softu czy hardware. Gdzie tam jeszcze testy jednostkowe lub integracyjne. Tylko jak ma być skalowalne i utrzymywalne to niestety jest warunek konieczny w szczególnie w dużej perspektywie czasu. To co próbujesz niby wdrożyć to nic innego jak produkty od Ropam czy Satela. Jakoś rynku nie zdobyły a skala zupełnie inna.
    "Trudno się do tego odnieść, bo nie wiem o czym piszesz. Chyba na siłę starasz się coś udowodnić" to że procek pobiera 0.1W to nic nie znaczy bo trzeba mu dostarczyć zasilanie z 230V, które wymaga 1-2W więc oszczędność jest żadna.
    Co do reszty pokaż obliczenia wykorzystania mocy, kosztów okablowania, kosztów urządzeń itd. Pokaż jakąś przewagę. Zrób testy związane z EMC i możemy wrócić do dyskusji.
    PS. 200ms to właśnie 5 razy na sekundę. Jak obwarujesz to właśnie arbitrażem to będzie 1-2 na sekundę pod warunkiem braku retransmisji. Zdaje sobie sprawę z tego że można budować rozległe sieci na RS czy innych interfejsach pollingowych tylko kwestia responsywności rozwiązania. Wszystko kwestia wymagań. Potem tylko się okaże że nagle trzeba obsłużyć jakieś ETH i znowu problem.