Часы на esp8266 и max7219 + android управление

Прикрутил api.apixu.com, все вроде работает. Сервер оказался более привередливый чем openweathermap, ему в запросе нужно явно указывать тип HTTP протокола, иначе дает ошибку 400. Кроме того, он выдает все положенные HTTP headers в ответе, а не голый JSON. Пришлось хедеры поскипать перед подачей на библиотеку. Хорошо фигурных скобок кроме как в JSONe больше нигде нет, и получилось 2мя строчками его выделить.
Кодов городов у apixu нет, но он понимает координаты, названия городов на английском, коды аэропортов и т.п.
Я пока поставил авто-определение по IP, выскочил какой-то непонятный город, километрах в 20 судя по координатам. Но погода правильная. API key нормально через веб интерфейс прошел, а в поле кода города нельзя ничего вбить, кроме цифр. JavaScript на странице, похоже, не дает.

Как бы эту проверку убрать?

 

Тут уже не раз доказывали, что этим часикам не нужен интернет для того чтоб ходить. И по крайней мере сутки они без него могут относительно точно продержаться.

 

Ну мы не робково десятка
А что будет, когда я df player начну прикручивать
Насчёт apixu у меня тоже была мысль, я даже там регнулся, но до реализации дело не дошло из-за нехватки времени, отложил. На данный момент на последней прошивке от Ивана, с погодой вообще не понятно что творится, и я даже не пойму в чём вообще там дело. Погоды на сейчас практически никогда нет, выскакивала как-то, несколько часов поработала, и опять пропала. Вот уже примерно сутки вообще пишет только на завтра, но цифры все нули. Точки все мигают. Ковырять пока некогда, забил.

 

Наверно.

Врет, как и любые прогнозные сайты.

 

Иван, в следующем релизе исправьте небольшую ошибку.
При выводе температуры принятой по MQTT в диапазоне от 0 до -1, знак теряется.
Когда перемножаются tMqtt3 и tMqtt5 для определения знака числа, в указанном диапазоне tMqtt3 равно нулю. Соответственно, умножаем на -1 и получаем ноль без знака.
У себя исправил так - поскольку использую только MQTT, то в функции showSimpleTempU анализирую знак числа по tMqtt5, ну и дальше всё нормально.

 

Странно, я не указываю.

Это да, немного надо обрезать ответ.

Это не джава а сам хтмл - делает проверку корректности ввода данных. В P_weаth.h - поправьте вот эту строчку

Код (C++):

<td><input type="text" class="field" id="cityID" value="{{cityID}}" class="form-control" pattern="[0-9a-zA-Z.]{1,32}"></td>

Спасибо. Постараюсь не забыть.

 

Мы скорее всего о разных вещах говорим. Я имел в виду не http:// префикс в URL, а указатель HTTP-протокола в GET-запросе типа HTTP/1.1
В версии для openweathermap его почему-то не было, но их сервер это пропускал. А apixu выдает ошибку, что в общем, правильно. При этом браузер сам это добавляет в запрос, и получалось, что в в нем все работало нормально, а при запросе из часов была ошибка, хотя оба запроса выглядели одинаково.
Я еще добавил обработку языков, текст для погоды выводится с учетом языка в веб-интерфейсе. Пока версию использую с файлами. Тормоза есть конечно, но терпимо.
Осталось сделать перевод названия города. По моему, проще всего добавить поле в веб-интерфейс и руками туда загонять название города на нужном языке, для вывода в бегущей строке. Сейчас пока название города на английском выводится.
А так все работает, и текущую погоду дает правильно, и прогноз такой-же, как от других источников. Кстати, прогноз они в течении дня уточняют.

В любом случае работает намного лучше openweathermap, те вообще полную ерунду иногда показывали.
Код в файл положил.

 

А мне казалось что User-Agent: ArduinoWiFi/1.1\r\n как раз и указывали на протокол.

Код (C++):

  if(lang == 0) weather_lang_apixu = "uk";
  if(lang == 1) weather_lang_apixu = "ru";
  if(lang == 2) weather_lang_apixu = "pl";
  if(lang == 3) weather_lang_apixu = "cs";
  if(lang == 4) weather_lang_apixu = "de";
 

Конечно не критично, но я вынес эту функцию во вкладки с переводами языков

Код (C++):

  tWeatrNot = "   Bez aktualizací počasí po dobu delší než 6 hodin!!!   ";
  tWeatrTN = "bez aktualizací počasí - ";
  if(printCom) {
    printTime();
    Serial.println("Text CZ.");
  }
  weatherLang = "cs";
}
 

Код (C++):

if(ESPclient.connect(weatherHost.c_str(), 80)) {
    String ESP_GET_String = String("GET /v1/forecast.json?key=") + weatherKey + "&day=1&q=" + cityID2 + "&lang="+ weather_lang_apixu + " HTTP/1.1\r\n" +
                "Host: " + weatherHost + "\r\nUser-Agent: ArduinoWiFi/1.1\r\n" +
                "Connection: close\r\n\r\n";
 

Мне кажется что вы запрашиваете только прогноз на сегодня.
Я запрашиваю на сегодня и на завтра.

Код (C++):

ESPclient.println(String("GET /v1/forecast.json?key="+ weatherKey +"&q=" + cityID + "&lang=" + weatherLang + "&days=2" + " HTTP/1.1\r\n") +
                "Host: api.apixu.com\r\n" +
                "Connection: close\r\n\r\n");

Кстати интересное решение

Код (C++):

  String line2 = ESPclient.readString();
  int json_start = line2.indexOf("{");
  line2 = line2.substring(json_start);

 

Кстати сегодня с Денисом тестили точность прогноза и пришли к мнению, что погода на сейчас которую вы получаете в запросе api.apixu.com/v1/forecast.json не совсем точная. Более точная погода приходит при запросе api.apixu.com/v1/current.json. Причем большая разница наблюдалась в первой половине дня.
По этому я таки вернул назад два запроса погоды.

 

Я тоже делал 2 запроса сначала, но для текущей погоды выдача была все время одинаковая, и я один запрос выбросил. Но, видимо, зависит от времени или расположения.
Могу код с 2мя запросами вернуть, лучше его использовать, раз такое дело.
А user-agent это отдельный параметр, в типу HTTP отношения не имеет. Я сначала думал, что им не нравится этот необычный клиент, пробовал даже десктопный агент ставить типa Mozilla... Но все равно вылетало. А как добавил HTTP/1.1 - все заработало.
А с days=1 или 2 нужно разобраться. Они пишут, что days это
Number of days of forecast required.
Выходит, что 1 это на завтра, 2 на послезавтра и т.д

 

Скорее это количество дней 1-7, включая и сегодня.
Запросите на большее количество и там есть даты

 

Понял я, что с днями происходило. Параметр называется days, а в коде у меня был day. А сервер apixu ни дзинь ни бряк, хоть бы ошибку показал.
Теперь даты вижу. Нужно запрашивать days=2, там данные на сегодня и завтра. А вот как лучше выводить прогноз?
Можно например с 0 часов до 12 дня выдавать прогноз на сегодня, а после на завтра. Нужно тогда прогноз на сегодня как-то назвать на разных языках - later today/далее сегодня/далi сьогоднi ? По польски/чешски/немецки не знаю. Хранить лучше в языковых вкладках соответственно .
Или можно до 12 дня показывать на сегодня, а после и до 12 ночи и на сегодня и на завтра. Но после обеда тогда строка будет длинная.
Что думаете по этому поводу?

 

Ну я практически так и сделал.
До 12 дня выводит: - Сейчас: температура, влажность и т..д, Сегодня: температура мин + мах и текстовое описание, Завтра - соответственно прогноз на завтра.
С 12 до 18 из Сегодня выводит только текстовые данные
Ну и после 18 только Сейчас и прогноз на завтра)))

Код (C++):

weatherStringZ = "";
  if(hour<18) weatherStringZ += tCurr + ":";
  if(hour<12) weatherStringZ += "   \212" + String(forecast_forecastday0_day_mintemp_c, 1) + "...." + String(forecast_forecastday0_day_maxtemp_c, 1) + "\202" + "C  ";
  if(hour<18) weatherStringZ += "   " + String(forecast_forecastday0_day_condition_text) + "     ";
  weatherStringZ += tTom + ":   \212" + String(forecast_forecastday1_day_mintemp_c, 1) + "...." + String(forecast_forecastday1_day_maxtemp_c, 1) + "\202" + "C";
  weatherStringZ += "     \213 " + String(forecast_forecastday1_day_avghumidity) + "%";
  weatherStringZ += "     \214 " + String(forecast_forecastday1_day_maxwind_kph, 1) + tSpeed;
  weatherStringZ += "     " + String(forecast_forecastday1_day_condition_text);
//  weatherStringZ += "     Видемость: " + String(forecast_forecastday0_day_avgvis_km, 1) + " км.";
//  weatherStringZ += "     Восход: " + String(forecast_forecastday0_astro_sunrise);
//  weatherStringZ += "     Закат: " + String(forecast_forecastday0_astro_sunset);
  weatherStringZ += "             ";

Слово "сегодня" перевел на все языки во вкладках с переводами)))

 

да, так отлично будет.
Нет у вас кстати готового кода для внешних датчиков с MQTT, чтобы к часикам подключать? У меня несколько штук работают, но пишут все в thingspeak.com, a до MQTT как то руки не дошли...

 

К сожалению нет.

 

В версии от 10.08 было значение LOW вместо HIGH от этого и показывает в новой версии все время 85
я у себя изменил на LOW и все заработало и еще заметил время отображения памятных дат не сохраняется на измененное. и когда стоит галочка на часовом поясе при перезагрузке часы уходят на час вперед

 

можете пожалуйста залить бинарник для прошивки часов (последнюю версию) , а то у меня через ардуино иде не прошивается, то библиотека не та, то это не правильно, а я просто хочу часы нормально работающие

 

В папке где основной скетч https://github.com/IZ76/ESP8266_Clock_Weather-station_Informer_with_WEB_interface

 

там только от 30.05.18
а я хотел последнюю версию

 

Посмотрите в этой папке https://github.com/IZ76/ESP8266_Clo...rface/tree/master/LED_clock_weath_v25.10.2018
файл с расширением *.bin