Hi Niclas, the proxy protocol is not really related to the lora-stuff ... it's just both related to plc4c and mynewt.
I know that with LoRa you wouldn't be sending a plc4x proxy request to a remote station and get a response. That far I've understood the concept. And the stuff my neighbor has to check are if the technical equipment is in an operational state. It's a dam for flood protection and the equipment must be in a state in which it could actually handle a flood. So, it's really interfacing with real PLCs. However, I have absolutely no idea if we would actually be allowed to even try this. I'm just trying to make up some use cases in which we could use open-source to solve problems I've seen. And I know there are several situations like this. Some folks go around manually checking water wells once a week, or other sort of invisible stuff where automation hardware is located in places, where there's no direct internet connection. I would love to try out using PLC4C+MyNewt as platform on these low power devices to automate some of the silly jobs. A completely different use case is the proxy protocol ... I just entered that into the proposal with some reasoning, because I thought it was something worth having in any case and this way the EU would finance it ;-) Chris -----Original Message----- From: Niclas Hedhman <[email protected]> Sent: Sonntag, 13. Februar 2022 13:20 To: [email protected] Subject: Re: Thomas ... you still around? On 2022-02-12 21:03, Christofer Dutz wrote: > In the end my final goal would be to have plc4c running in a mynewt > application, which is running on some super-low-power STM32 devices. > One of my development boards has a LoRaWan interface, so in the end > I'd love to send requests to the device and have the responses sent > back via LoRaWan to devides out in the field. Sorry to intervene... I work a lot with LoraWAN and somehow this sounds like "All I have is a hammer so all problems look like a nail." kind of thinking. LoraWAN operates on the basis that uplinks are relatively cheap, albeit limited in frequency, and downlinks are much more scarce resource, so "request/response" messaging is discouraged in general. And practically all devices simply send a packet at some configured interval, with as few bytes as possible (to minimize airtime). I use The Things Network (have not bothered to deploy my own stack, but uses the community managed one), and it receives/concentrates the LoraWAN packets, and I have a choice there to request/reply, MQTT subscribe or webhook (POST to URL) upon data arriving (but after decoding of binary bytes to extensive JSON with a lot of useful metadata). I would be happy to guide you or answer any questions, because I think the request/reply "mentality" from PLC world doesn't really belong in the LoraWAN world. About your neighbor; I assume it is pH, phosphate and similar measurements to be made, maybe measuring the level. It is very likely that dedicated LoraWAN sensors are available off-the-shelf, and if not, just a generic analog inputs device with conventional sensors would be my solution. And then connect it all to my upcoming http://sensetif.com (service at https://sensetif.net) for storage and visualization. ;-) (beta-launch planned for March) Cheers Niclas
