Bascom - Atmega1284p + ESP8266 - wysyłanie danych do Domoticz

Witam
Walczę z wysyłaniem danych do Domoticz. Domoticz zainstalowany na Orange Pi Zero działa poprawnie.

Wykorzystałem sposób wysyłania do ESP8266 Kolegi Niveasoft. Co prawda wysłał on dane do Thingspeak'a, ale nieco go przerobiłem.



Teraz logi z terminala
Wysyłane:


Odbierane:


Niby przesyła, ale Domoticz tego nie widzi.
Gdy zrobię to przez stronę, czyli
http://192.168.0.101:8080/json.htm?type=command¶m=udevice&idx=11&nvalue=0&svalue=16.8

to wtedy dodaje bez problemu i wysyła odpowiedź
"status" : "OK",
"title" : "Update Device"

Może to kwestia ustawień samego Domoticz

widziałem ten link


początek wynika ze składni, jaką trzeba wysłać do Domoticz, czyli


zrobiłem to nieco inaczej i terminal podaje



Znalazłem jeszcze coś takiego w języku LUA

Czyli trzeba zmienić podejście w podprogramie. Z tym definiowaniem też się staram tak robić, np. w przypadku adresu IP, czy haseł do routera

Ale w takim razie trzeba to rozdzielić na kilka "Print"ów.
czyli coś takiego ?

oczywiście w uproszczeniu, bo trzeba by sprawdzać, czy nie ma błędów przy wysyłaniu

Coś o HTTP/1.1
Żądanie wysłane przez przeglądarkę w celu pobrania wskazanej strony wygląda (po drobnych skrótach) w sposób następujący (Inspectors, Raw):

GET /lesson01/index.php HTTP/1.1
Accept: image/gif, image/jpeg, (...)
Accept-Language: en-US,pl;q=0.5
User-Agent: Mozilla/4.0 (compatible; ...)
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Host: bootcamp.threats.pl

W pierwszej linii znajduje się kolejno metoda (GET) adres pobieranego zasobu (bez nazwy hosta), wersja protokołu HTTP (HTTP/1.1). Kolejne linie żądania to tak zwane nagłówki. Ich struktura jest prosta - nazwa i po dwukropku wartość. W tym wypadku przeglądarka informuje serwer o akceptowanych przez siebie typach plików (Accept), języku (Accept-Language), swojej wersji (User-Agent), akceptowanych kodowaniach (Accept-Encoding). Nagłówek Host mówi o hoście, z którym się przeglądarka łączy oraz o tym, że z powodów wydajnościowych przeglądarka chce utrzymać otwarte połączenie z serwerem (Connection: Keep-Alive).

maximus22_kr napisał:

/json.htm?type=command¶m=udevice&idx=

czy tak samo masz w programie? czy command & param

W kodzie programu jest prawidłowo - to edytor Elektrody to zmienia

"Wydaje" mi się, że coś takiego powinno działać:

ale terminal pokazuje to :


Oczywiście ten dziwny znaczek po "command" to nadal sprawka edytora Elektrody.
Nie wiem, czy to wina tych wait'ów pomiędzy printami? - tak na "pałę" bez sprawdzania

Jakiego typu jest device o idx=12?
Większość, jak nie wszystkie operują tylko na svalue, a u Ciebie jest puste (svalue=co?)

Wróć do programu z pierwszego postu i wyświetl co zwraca json (93 bytes rec?).
Po czym wnioskujesz, że nie działa skoro zwraca OK? Może trzeba odświeżyć stronę?

Idx=12 to Temp

svalue nie jest raczej puste
Kod:


powoduje wysłanie

No znowu ten znaczek po command

Nic się nie dodaje do bazy - nadal stan z 04.05.17 kiedy "ręcznie" przez przeglądarkę poszło bez problemu

Rozumiem Twoje samozaparcie, też nie lubię jak mnie "maszyna" wodzi za nos.
Wygląda, że wszystko robisz dobrze - w dziedzinie AT comand nie mogę ci pomóc.
Jeśli ważniejszy dla Ciebie jest cel niż droga, to rozważ przejście na MySensors.
Mam podobny układ - ESP po RS gada z kotłem gazowy Viessmann, zbiera informacje z sensorów kotła i wysyła stan wszystkich czujników przez Wifi do domoticza. Jedyne co trzeba zrobić to dodać bramkę w urządzeniach

Następnie po połączeniu bramka "prezentuje" wszystkie swoje czujniki do domoticza z automatu. Jedynie co trzeba zrobić to je ponazywać.


Kilka linijek kodu i wszystko się aktualizuje. Potrzeba znać w stopniu minimalnym aruinoIDE i C arduino. Wszystko działa zgodnie z oczekiwaniami bez grzebania się w json i sqlite.

No to mam "zagwozdkę".
Ja zrobiłem to według jednego z opisów:
Utworzyłem Dummy (Does nothing, use for virtual switches only)
Kliknąłem Utwórz Wirtualne czujniki
Pododawałem czujniki temperatury, ciśnienia, które mają swoje IDX


Terminal pokazuje wysyłany ciąg
> GET http://192.168.0.154:8080/json.htm?type=command¶m=udevice&idx=12&nvalue=0&svalue=16.9

Wpisanie w przeglądarce
http://192.168.0.154:8080/json.htm?type=command¶m=udevice&idx=12&nvalue=0&svalue=16.9
powoduje aktualizację
no i na tym utknąłem

Witam ponownie
Gdy aktualizuję przez przeglądarkę to mam po chwili odpowiedź
status "OK"
title "Update Device"
Gdy wejdę w nagłówki to mam coś takiego:


ogólnie mam problem żeby wysłać coś więcej niż



później każda próba wysłania kończy się:


<html><head><title>Bad Request</title></head><body><h1>400 Bad Request</h1></body></html>CLOSED


Może problemem jest ilość znaków ?
Odpowiedź ze strony:
Content-Length 53

Odpowiedź z modułu:
Content-Length: 89
Dodano po 2 [godziny] 47 [minuty]:
Znalazłem podobny wątek na Elektrodzie, tylko tam Link autor miał problem z aktualizacją danych w sieci wewnętrznej ( czyli tak jak ja ), natomiast gdy serwer był na zewnątrz to nie było problemu.
Na podstawie informacji z tego wątku powinienem wysyłać tak:


tylko, że to też daje:

Witam
Niestety dalej mi się nie aktualizuje.

Pewnie zanudzam Kolegów.
Mam pytanie, czy wysyłać mam tak:

czy


Niestety opisów podobnego problemu jest sporo ( wszystkie w Arduino ) i rozwiązań też, że powinno się wysyłać np.
GET /path/to/page.html HTTP/1.1
Host: localhost
User-Agent: wget/1.12
"\r\n" -dodatkowy print

lub

GET /raw/1nmeKaux HTTP/1.1
Host: domena.com
Connection: close
Accept-Charset: ISO-8859-1,UTF-8;q=0.7,*;q=0.7
Cache-Control: no-cache
Accept-Language: de,en;q=0.7,en-us;q=0.3
"\r\n" -dodatkowy print

lub

Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding gzip, deflate
Accept-Language pl,en-US;q=0.7,en;q=0.3
Connection keep-alive
Cookie AffiliatedA=1
Host 192.168.0.154:8080
Upgrade-Insecure-Requests 1
User-Agent Mozilla/5.0 (Windows NT 6.1; rv:53.0) Gecko/20100101 Firefox/53.0
"\r\n" -dodatkowy print

lub GET /girls HTTP/1.1
Host: domena.com
User-Agent: ESP8266_HTTP_Client
Connection: keep-alive
"\r\n" -dodatkowy print


Próbowałem też "ręcznie" przez terminal - idzie dobrze do momentu wysłania " HTTP/1.1"

No zgadza się trochę zaczynam się gubić.
Znalazłem coś takiego w arduino ( heh, jeszcze trochę i chyba się tym bardziej zacznę zajmować ):


Znaki "{013}{010}" są liczone do długości ciągu
czyli uwzględniając te znaki 10 i 13 w Bascom, to powinno być tak ( port chyba też powinien być ) :

Znowu nieco ponudzę, ale
na razie udało mi się ręcznie przez terminal zaktualizować dane - program terminal ( Terminal v.1.9b ) ma zaznaczone dodawanie znaków końca linii.


Problem jest z tymi znakami 13 i 10, jak doliczyłem do rozmiaru wysyłanego ciągu dwa znaki to poszło bez problemu.

Z Realterm próbuję ale coś nie pokazuje znaków końca, tylko
GET /json.htm?type=command¶m=udevice&idx=13&nvalue=0&svalue=24.6 HTTP/1.1
Host: 192.168.0.100:8080
Connection: close
Accept: */*
User-Agent: Atmega-Client (compatible; esp8266 Lua; Windows NT 5.1)
może coś źle zaznaczyłem w opcjach.

Teraz mam głupie pytanie, czy doliczać do AT+CIPSEND te 2 dodatkowe znaki, czy zdać się na Bascom i zostawić tak:

No i wreszcie działa. Sprawdzałem na temperaturze, wilgotności i ciśnieniu z BME280.
Na razie to "półautomat", bo nie sprawdza odpowiedzi , tylko co 1 sekundę wysyła kolejną paczkę danych do ESP8266



Czyli tak, jak pisał Kolega Niveasoft, trochę mi się namieszało ze znakami CR LF.

Teraz tylko pasuje dodać jakąś kontrolę odbieranych znaków - coś podobnego jak Kolega Niveasoft na swojej stronie odnośnie wysyłania danych do Thingspeak'a. Czyli "zagnieździć" Case w Case.

Witam
Przerobiłem kod z poprzedniego posta, tak żeby w podprogramie reagował na to co przyjdzie z UART.
Niestety "stoi" na początku, tzn. połączył się, ale próbuje to zrobić ponownie - nie przechodzi do kolejnego Case


W terminalu mam:


Założenie było takie, że wysłanie AT inicjuje wysłanie, a odpowiedź - OK powoduje połączenie i odpowiedź modułu - CONNECT, co powinno przenieść do następnego Case. Tego nie robi.

Z tego co pamiętam z Bascom Select Case jest czymś podobnym do IF Else.
Ty zamykasz Select Case po każdym porównaniu.
Zagnieździłeś dwa SELECT CASE i zbyt wcześnie wychodzisz z wewnętrznego warunku.
Z Select Case Com1_str powinieneś wyjść tylko raz na końcu porównania.
Tak mi się wydaje.

Ale kod Kolegi Niveasoft wysyłający dane do Thingspeak'a działa na podobnej zasadzie - wykrywa OK i SEND OK. Co prawda tam jest prościej, bo jest tylko jeden ciąg do wysłania - tutaj jest jest więcej, no chyba, żeby uprościć ( ale większa wartość zmiennej Domoticz_cmd ) i wysłać tak:

ale to zapewne nic nie zmieni, jeśli będzie błąd logiczny w kodzie.

natomiast być może faktycznie jest coś z tym zbyt szybkim wyjściem z wewnętrznego warunku - wygląda na to, że bardzo szybko odsyła drugie OK ( przynajmniej na terminalu to widać ) i program nie przechodzi do następnego Case tylko sprawdza i "zauważa" drugie OK będąc nadal w Case 0, czyli próbuje się znowu łączyć.

Cytat:

Dlaczego po wysłaniu komendy "AT+CIPSTART=.." od razu nie zmienisz Domoticz_krok na wyższy i tam nie poczekasz na "CONNECT"?

no i właśnie to jest pierwszy błąd logiczny.
Drugi to wzięcie do porównania złe wyrażenia.
Zmieniłem od na :


W sumie działa, czasem mam:


to pewnie przez brak połączenia ( tak się dzieje zaraz po wgraniu kodu, jak wyłączę i włączę zasilanie to OK )

lub


Pasowałoby jeszcze obsłużyć ERROR przy problemach z połączeniem i Bad Request, można by jakiś licznik prób, żeby się nie zapętlił.