• 10 dec 2017: forum version update. In case of issues use this topic.
  • 30 nov 2017: pilight moved servers. In case of issues use this topic.
Hello There, Guest! Login Register


Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Remote GPIO standard: Modbus over RS-485
#1
Is it an option to add Modbus over RS-485 to pilight?  It is a good match in terms of simplicity and unleashes remote GPIO actions over a simple twisted pair.

RS-485 in summary:
  • RS-485 can easily be connected to an RS-232 port
  • RS-485 uses symmetric signals over one twisted pair: long distances, high speeds
  • RS-485 implements a bus: 32 devices on a wire; more with amplification
  • RS-485 commonly runs Modbus as its protocol
Modbus in summary:
  • Modbus is a standard for addressing input/output devices
  • Modbus can run over RS-485 or TCP or TLS
  • Modbus assumes a single bus master that polls slaves
  • Modbus supports up to 247 slaves; and has a broadcast address
  • Modbus slaves typically have a configurable address
  • Modbus serial frames: SLAVE,COMMAND,DATA,CRC16
Typical devices range from low-cost to high-cost and include:
  • Relay blocks for output, switches for input
  • Sensors for temperature, humidity, ...
  • Thermostats with programmable setpoints
  • Energy meters: W, Wh, V, A, VAh, cos(φ)
There are cheap and simple ways to get on the bus for USB as well as for RS-232 (3V3, 5V or standard).

I think it makes a lot of sense in the pilight platform!
 
Reply
#2
Of course, all additions are welcome. The hardware modules can be written in Lua so adding new hardware support should be fairly easy.
 
Reply
#3
(07-13-2019, 11:03 AM)curlymo Wrote: Of course, all additions are welcome. The hardware modules can be written in Lua so adding new hardware support should be fairly easy.

I though you would say that ;-)

I've been looking through the C code, and found it looking non-trivial.  Not sure where to find Lua information.

There seem to be module and interface behaviours but these are not documented, is that correct?  That makes it more difficult to add something like this, which would otherwise be simple enough.
 
Reply
#4
Quote:I though you would say that ;-)
Because people often don't realize how much freaking time developing pilight costs. Not that i'm not happy to do so, but as long as i can follow my own pace in it.


Quote:I've been looking through the C code, and found it looking non-trivial.
Why?

Quote: Not sure where to find Lua information.
On the lua website and the pilight manual section 'Development'.

Quote:There seem to be module and interface behaviours but these are not documented, is that correct?  That makes it more difficult to add something like this, which would otherwise be simple enough. 
If my documentation isn't complete enough, give me example and i'll add it.
 
Reply
#5
Thanks for commenting, curlymo!

The clean structure in spite of a scattered hardware landscape tells me that you put in good effort, hence the smile. Note that the topic of "Feature Requests" suggests openness to such founded requests, which is why I tried that first.

I thought the C code was non-trivial because I saw conventions without seeing quickly where they came from. I had overlooked the Development section though, which I should indeed study. In general, I should study pilight better, and evaluate if it can do what I want it to do.

Having found a decent-looking minimalistic Modbus TCP relay, which isolates serial-port specifics and avoids locking out other applications from the same Modbus devices, I now believe this is a better mechanism than direct RS-485 to get Modbus incorporated. Direct RS-485 with static configuration may be interesting in a future version that serves the smallest platforms who have just an UART for this.
 
Reply
#6
Quote: I thought the C code was non-trivial because I saw conventions without seeing quickly where they came from. I had overlooked the Development section though, which I should indeed study. In general, I should study pilight better, and evaluate if it can do what I want it to do.
In general, pilight tries to respect all design patterns that are common in software development. Like threadpooling, consumer patterns, async io, modular structure, etc. I understand it's confusing to understand the difference between staging and rewrite, but there are some posts in which i explained that more detailed.

Another important goal is to make pilight super modular. That means that everything inside pilight should be considered a module:
- The storage backend
- The hardware interfaces
- The protocols
- The event functions, operators and actions
- The lua c interfaces
- The platform interfaces (through wiringX)


The hardware modules, all event modules, and some storage backends are already ported to lua making module development even easier.

Quote: Having found a decent-looking minimalistic Modbus TCP relay, which isolates serial-port specifics and avoids locking out other applications from the same Modbus devices, I now believe this is a better mechanism than direct RS-485 to get Modbus incorporated. Direct RS-485 with static configuration may be interesting in a future version that serves the smallest platforms who have just an UART for this. 

I would love that. pilight is written in C to have the highest performance for low-level interfacing like GPIO or serial etc. It also makes it easier to run it on a multitude of platforms like routers and such.
 
Reply
#7
I've been evaluating pilight further, and to avoid an open-ended forum entry which might create false hopes:
I am deferring this work.
I will continue to listen in on this topic, though.

There are two reasons for deferring:

  1. I have difficulty getting into pilight on the basis of manual; it immediately dives in with constraints on and examples of the various concepts, and though they are probably very well-designed, I cannot find a place where they are defined as stand-alone concepts, nor a place where the general relations are explained that pilight makes between them.  I'd need this information to be able to extend it properly.
    I'd like to suggest adding such generally descriptive documation for new-comers without prior knowledge of pilight.  I'm perfectly willing to proof-read.  [this one @curlymo]
  2. I would also have to work on the rules to do what I have in mind, and since this is still developing in my mind it is probably not optimal to do it in pilight.  Working towards it may however be good.
For the record, what I have in mind is resource management.  I want to take note of solar-generated electricity and divide it among devices that store their results so they can be scheduled.  Things like boilers, infrared heating and fridges can be flexibly and more optimally allocated by integrating them.  Resources may be prioritised, and priorities may even increase with time ("this room should be nice and warm by the time I get home" or "the boiler really needs its regular anti-Legionella boost before the day is over").

Though pilight's rules might be expanded to do this, the C language and already-present structures are likely to make experimentation with the concepts for resource allocation more complex than stand-alone.  Also, I believe it is better to find the minimum set of concepts needed to do this, and make the smallest possible contribution to pilight.

I do have pilight on the radar as a technology to incorporate more than "just" RS-485 devices in this scheme, so chances are I will (have to) pick this up later.  For now, pilight seems to work on smaller devices than the coarser ones that I want to allocate.  So I will start off at GitHub, as GroenGemak, working on a Solbus system in Python.
 
Reply
  


Possibly Related Threads...
Thread Author Replies Views Last Post
  [Supported] gpio-platform raspberrypi4 vanillaice30 2 207 09-20-2019, 09:38 PM
Last Post: curlymo
  GPIO PWM dimmer koos147 0 1,228 10-13-2015, 09:45 PM
Last Post: koos147
  Nano rx/tx gpio control extention creamers 10 4,302 07-13-2015, 06:56 PM
Last Post: curlymo
  PWM Dimming via GPIO? Xoneoo 1 2,655 02-08-2014, 11:07 PM
Last Post: curlymo

Forum Jump:


Browsing: 1 Guest(s)