TD-er
commented
5 years ago I added some enters in your post to make it better readable.
Open mackowiakp opened 5 years ago
TD-er
commented
5 years ago I added some enters in your post to make it better readable.
TD-er
commented
4 years ago I have read your issue again and I still don't think I know what your request actually is. Can you give an itemized summary of what needs to be done and where?
Is it that you want to get a return value from the sendtohttp? Or should sendtohttp trigger an event in case of an error? (error being "timeout" or "404" or something like that)
mackowiakp
commented
4 years ago I also wonder what return value should be. And to be honest - I have no idea. It is currently the case that regardless of whether the SendToHTTP request is received by the server or not, it returns OK. Which in practice means "OK, I sent a request, but whether it arrived - I do not know". I tested it through the "Tools" -> "Command" option. In my case, the fact that the HTTP request did not reach Domoticz was a bug in the configuration of iptables on RPi. But the reasons can be different, of course. Anyway, from ESPeasy I couldn't even tell if anything had reached the server.
mackowiakp
commented
4 years ago After a few minutes of reflection, I thought so. "If you don't know what to do, follow the standards." So maybe for example "404" (or another number returned by the server) or "timeout" (other number?) returned in case of transmission problems. I mean about something like %eventvalue%. so return number should be place in that variable. I don't know if it's possible, it's just a my proposal. And one more thing. I want to enter measurements in future not to Domoticz and then to InfluxDB but directly from ESPeasy to InfluxDB, with presentation based on Grafana. So proper work of SendToHTTP is essential.
TD-er
commented
4 years ago SendToHTTP should also be adjusted for sending to services like ThingSpeak. That service now requires to wait for a reply (not closing the connection immediately). So I was thinking of adding a new command which does have the following:
mackowiakp
commented
4 years ago Hmmm. It sounds very ambitious. In my opinion (based on previous experience with SentToHTTP), all of these properties are something extremely desirable.
TD-er
commented
4 years ago Ambitious, maybe. But better do it right than having something that needs patching later on.
I have Domoticz on RPi. RPi is equipped with UPS, on which RPi can work at least for 4 days. nodeMCU do not have UPS.
In addition - as you know - nodeMCU reset themselves from time to time, and even hang. I wrote the rules that reboot nodeMCU after 15 minutes if they hang. Either way, after losing power or after "hanging", I need to restore, for example, the state of the relays or the contents of the displays. They sometimes display a value from a sensor that is connected to a completely different nodeMCU or RPi itself. Additionally, the state of the relays for example, may have changed during a power outage, according to the schedule recorded in Domoticz. Therefore, during boot nodeMCU I send SendToHttp from nodeMCU to Domoticz, who "presses" the dummy button in Domoticz. This, in turn, launches the LUA script in Domoticz, which in turn sends to the nodeMCU set of the parameter values downloaded from the Domoticz database, which should have the nodeMCU at that time and writes them to the user variables. It's just that I don't know if, for example, the "zero" values themselves are correct or their zero value is due to the fact that they have not been transmitted from Domoticz to nodeMCU. So somehow you need to check that the transmission took place. If I cannot do this at the protocol level, I use workaround.
First, I reset one user variable (semaphore), send SendToHTTP to Domoticz, the LUA script sends data and sets - previously zeroed - user variable to 1. This only confirms that I can trust the downloaded data. Well, only that it should happen at the protocol level and not in the rule.