ESP8266 v1.8 BETA
Poprawka wrzucona
Teraz dla Sonoff-ów czujnik temperatury jest na GPIO14, który jest wyprowadzony na dodatkowym pinie
Przemek, ostatnio w "supla_esp_devconn.c" na Github-ie zablokowałeś funkcje: supla_esp_devconn_send_channel_values_with_delay_cb(void *timer_arg), supla_esp_devconn_send_channel_values_with_delay(void) ( to zapewne one dublowały mi komunikaty z funkcji debugującej), ale jest w nich odwołanie do funkcji supla_esp_board_send_channel_values_with_delay(srpc) występującej również w plikach z definicjami poszczególnych płytek.
Nowe firmware kompilują się z przyblokowanymi funkcjami, ale np. ostatnio przygotowany przeze mnie moduł gate_module_mem z taką blokadą nie do końca działa poprawnie.
Czy, w tych plikach należy zrobić zmiany?
Nowe firmware kompilują się z przyblokowanymi funkcjami, ale np. ostatnio przygotowany przeze mnie moduł gate_module_mem z taką blokadą nie do końca działa poprawnie.
Czy, w tych plikach należy zrobić zmiany?
Te funkcje były dlatego, ze nie zawsze statusu przechodziły do serwera. Ostatnio znalazłem dlaczego tj. espconn_sent czasami zwraca INPROGRESS
i wtedy "gubił" się pakiet z uwagi na to, że w supla_socket nie przewiduje, że nie dało się czegoś wysłać. Docelowo muszę przebudować supla_socket aby zostawiał w buforze to co nie wyszło, ale to dość wrażliwy obszar, którego na razie nie ruszam bo dotyka wszystkich platform, a nie mam czasu na testy. Dlatego rozwiązałem to póki co dodając dodatkowy bufor w ESP
https://github.com/SUPLA/supla-core/blo ... onn.c#L203
Możesz po prostu zahashow-ać odwołania do tych funkcji.
i wtedy "gubił" się pakiet z uwagi na to, że w supla_socket nie przewiduje, że nie dało się czegoś wysłać. Docelowo muszę przebudować supla_socket aby zostawiał w buforze to co nie wyszło, ale to dość wrażliwy obszar, którego na razie nie ruszam bo dotyka wszystkich platform, a nie mam czasu na testy. Dlatego rozwiązałem to póki co dodając dodatkowy bufor w ESP
https://github.com/SUPLA/supla-core/blo ... onn.c#L203
Możesz po prostu zahashow-ać odwołania do tych funkcji.
Trochę się pobawiłem i w przypadku płytek korzystających z kanałów z SENSOR jak, np. gate_module należy jednak zmodyfikować plik z definicją płytki, a mianowicie w przypadku kanału 2:pzygmunt pisze:Możesz po prostu zahashow-ać odwołania do tych funkcji.
to :
srd->channels[2].Number = 2;
srd->channels[2].Type = SUPLA_CHANNELTYPE_SENSORNO;
srd->channels[2].FuncList = 0;
srd->channels[2].Default = 0;
srd->channels[2].value[0] = 0;
zmienić na :
srd->channels[2].Number = 2;
srd->channels[2].Type = SUPLA_CHANNELTYPE_SENSORNO;
srd->channels[2].FuncList = 0;
srd->channels[2].Default = 0;
srd->channels[2].value[0] = gpio__input_get(B_SENSOR_PORT1);
i analogicznie kanał 3, bo inaczej nie działa.
Moja kompilacja gate_module_mem z takimi zmianami, też już działa bezproblemowo w v1.8.
Konieczna jest modyfikacja źródeł na Github-ie (tak myślę, bo zawsze mogę się mylić).
Hmmm. On i tak stany jeszcze raz powinien wysyłać przy rejestracji. Celowo to tam pomijałem bo nie było potrzebne.
Proszę... tak jak w tym opisie: viewtopic.php?f=18&t=272&p=3604#p3520
- Załączniki
-
- sonoff.rar
- (198.85 KiB) Pobrany 177 razy
TEORIA jest wtedy gdy wszystko wiemy i nic nie działa
PRAKTYKA jest wtedy gdy wszystko działa a my nie wiemy dlaczego
My łączymy teorię z praktyką czyli nic nie działa i nikt nie wie dlaczego
PRAKTYKA jest wtedy gdy wszystko działa a my nie wiemy dlaczego
My łączymy teorię z praktyką czyli nic nie działa i nikt nie wie dlaczego
slawek pisze:Proszę... tak jak w tym opisie: viewtopic.php?f=18&t=272&p=3604#p3520
Witam
Niestety coś u mnie nie działa
niby wgrywa, ale później brak jakiegokolwiek odzewu, po wgraniu s powrotem 1.6 działa
Baudrate: 115200
Flash Size: 1MByte
Flash speed: 40Mhz
SPI Mode: QIO
ale zauważyłem, że w wersji 1.6
pierwszy plik ma 35k a drugi 238k
natomiast w wersji 1.8
pierwszy plik ma 2k a drugi 276k
czy tak powinno być taka różnica przy pliku boot ???