#studbaza #pracbaza #automatyka #embedded
LvL 25. W tym roku planowałem zacząć zaocznie magisterkę z elektrotechniki i telekomunikacji po 2 letniej przerwie od inż, ale zrobiłem sobie rachunek zysków i strat, no i wychodzi że więcej stracę. Obecnie mam spoko pracę, 5k na rękę i możliwość brania nadgodzin w opór, w soboty i w niedzielę również, więc ostatecznie wychodzi niezła kasa, na tyle, że mogę
LvL 25. W tym roku planowałem zacząć zaocznie magisterkę z elektrotechniki i telekomunikacji po 2 letniej przerwie od inż, ale zrobiłem sobie rachunek zysków i strat, no i wychodzi że więcej stracę. Obecnie mam spoko pracę, 5k na rękę i możliwość brania nadgodzin w opór, w soboty i w niedzielę również, więc ostatecznie wychodzi niezła kasa, na tyle, że mogę





























Zrobiłem prosty system IoT bazujący na MQTT i JSONach. Serwer odbiera wiadomość, robi dispatch i przekazuje żądanie do konkretnego interfejsu, który parsuje requesta, składa odpowiedź i publikuje na MQTT. Kolekcjonowanie danych do złożenia odpowiedzi naturalnie odbywa się na różne sposoby (komunikacja po fizycznych interfejsach z czujnikami) w zależności co jest żądane. Jednak czuję, że architektonicznie mogłoby coś zagrać lepiej jeśli chodzi o budowanie odpowiedzi.
Chodzi mi po głowie stworzenie jakiegoś generycznego buildera, ale
Zewnętrzny interfejs zatrzymaj w aplikacji serwera i tam zrób logikę która będzie parsować requesty i na tej podstawie, delegować konkretne zadania do
@Parseval: jak nie masz wspólnego zachowania dla wiadomości to co możesz abstrachować? Powinieneś mieć dispatchera, który robi switch po typie wiadomości przychodzącej i tak robisz logikę dla każdej