Здравейте, търся облачна платформа, на която да мога да кача мое приложение, което събира и анализира сензорни данни. Можете ли да ми дадете някакви съдвети?

Много са, и изборът не е лесен, особено с толкова лаконично дефинирани изисквания...
Аз започнах преди доста години с thingspeak на матлаб. Лесно се подкарва, елементарни http заявки, по-късно май добавиха mqtt. Може да се self host-ва, но беше по-стара версия и има перипетии да се подкара - мисля че беше на ruby и на ubuntu 14.04 мислено да върви. На по-нови линукси почват проблеми с зависимости и версии.
От какво ще качваш данните? Ако е някаква сдк/платформа ще ти подскаже какво се поддържа "out of the box". За най-бързи резултати аз ползвам espeasy с esp8266 - оттам имам директна връзка към много услуги - споменатия thingspeak е само едно от многото.
Ако искаш нещо на по-ниско ниво и ще правиш собствено решение (от ембедед страната) виж популярните бази и "front end" продукти - influxdb и graphana примерно. Оттам можеш да захванеш търсенето докато разплетеш докрай.

Използвам XBee сензори. Digi съпорта не ми предлагат много възможности на тяхната платформа. Проложението, върху което работя трябва да събира данни от сензори за температура, влажност... и ще извежда средна стойност от измерената температура за три дни назад например. Приложението ще се състои от две части - визуална (HTML) и оперативна/изчислителна (pithon). До колкото разбирам нещата (моля поправете ме ако греша), визуалната част трябва да бъде на облак, а изчислителната на сървър, и плюс това трябва да намеря метод да свържа данните от сървъра с приложението в облака (извинете ако се изразявам аматьорски). Някакви съвети?

Аз бих описал нещата така:
1. Сензорите
- мерят моментна стойност
- "публикуват" я
- може да буферират определен брой отчети или интервал от време и да качват (публикуват) накуп повечко данни за да спестят ток - установяването на връзката яде много ток; в зависимост от времето за реакция, което се гони, това трябва да може да се конфигурира - най-икономично ще е сензора да буферира в рам докато се напълни, но това може да са няколко дни данни и може да не е приемливо
- забравят какво са мерили досега и чака да дойде времето за следващо мерене
2. Сървър/брокер
- е нещото, до което достигат публикуваните данни
- примерно mqtt брокер - най-добре "hosted" някъде от надеждна фирма/доставчик за да няма downtime
- позволява след него да започнат няколко вериги от услуги, който да ползват данните
3. Базата данни дето се очаква да събира историята
- time series им викат - примерно influxdb
- може да е на същия облак, може и да друг
- няма сложни схеми и таблици - time series лог на всички измервания с таймстампа на всяка точка (разбира се поотделно за всеки сензор/нод)
- дотук, както се вижда, никаква преработка - само транспорт и история
Оттук насетне можеш да сложиш директно graphana или нещо подобно за визуализация (по модерному - frontend).
Ако го правиш ти би могъл да скриеш цялата визуализация (фронтенд) в клиентската част на web страничката - в javascript библиотеки. Търсиш API за заявки към базата от JS в страничката и когато решиш да показваш графика ти трябва начална дата, крайна и базата ще ти върне данните (базата е по модерному backend, щото обикновено там имаш и допълнителни обработки от типа на намиране на средна стойност, филтриране и тем подобни). За твоя случай, поне за демонстрация, не ти трябва сигурно да правиш сложни обработки/трансформации.
Ако погледнеш споменятия thingspeak (има му сорсовете в github) той работи по подобен начин - клиентската страна (в броузъра) е доста тежка и реално си пита за големи масиви данни и ги получава по json. Ако му поискаш 10000 точки да визуализира, дори на pc се замисля.
Номерът е да не се опитваш да обработваш данните ПРЕДИ базата - примерно да усредняваш, филтрираш и т.н. - това само води до загуба на информация. Абсолютният максимум данни са всички събития от сензорите - за намаляване на обема данни за съхраняване си има компресии, има политики за почистване ("пазим последните 12 месеца и трием по-старите") и т.н. Данни не се спестявам на принципа "чакай да видя тавана - ами.. май на 15 минути ще пишем по една...". Или по друг начин казано - имането не е като нямането - лесно е да изтриеш по-късно каквото не ти трябва, ама ако не си го съхранил нямаш шанс да направиш нищо.
Това ме навежда на друго - както казахме събирането трябва да може да се конфигурира - през колко време да мери, колко точки да буферира преди да ги прати накуп (ако изобщо правиш тая оптимизация), да прескача ли пращане ако промяната е под 0.1 градуса, и т.н. Най-просто е за времето - да приемем че мериш на определено време и пращаш - това време трябва да може да се конфигурира и променя - не само при билд на софтуера, ами и по време на работа. В смисъл по същия начин, по който се закачаш за да пратиш данни, трябва и да си готов да получиш промяна на параметри - например времето, прозореца за прескачане, смяна на резолюцията, и каквото друго има сензора ти.
Ако ползваш publish-subscribe, ала-mqtt, получаваш лесен начин да се случва това - когато се закачиш към брокера да пращаш последното измерване се абонираш и за параметрите си. Така ако някой има да ти казва нещо (например потребителя че иска вече на 5 минути да мериш) ще получиш уведомлението и ще конфигурираш таймера.
Към брокера по-горе могат да се закачат различни обработващи клиенти - единия както казахме е базата например, в която всяко пращане на измерване влиза в една таблица. Към същата точка ("получено е ново измерване") закачаш втори клиент - той смята средно на 24 часа и пише в друга таблица на базата веднъж на 24 часа. Това ако някой иска лесно и ефективно да получава преработени резултати - макар че същото може да се случи при поискване, използвайки няколкото хиляди резултата през няколко секунди от даденото денонощие.
Ако някой реши че иска резултатите да се обърнат в булева променлива "над нулата / под нулата" може да се сложиш следваш процес, който да получава всяко измерване, да проверява > 0 или не, и да вписва когато се промени. Не че трябва да вписва - по-скоро изходът от такива обработки (булевата променлива) се публикува в mqtt-то за по-нататъшно ползване (който иска да я пише в база, който иска да пуска отоплението, да светва лампа,...)

Edit: ето малко по-презентабелно:
https://www.grafanacon.org/2019/presentations/GrafanaCon_LA_IoT_Workshop.pdf

https://github.com/hwwong/ESP_influxdb

https://medium.com/@teebr/iot-with-an-esp32-influxdb-and-grafana-54abc9575fb2

Благодаря за помоща! На пръв поглед ми изглежда малко сложно, но ще се пробвам.