• 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
[Done] Updateable protocols and hardware modules
#1
Question 
Again i need your thoughts on something. For a few weeks i've been thinking about separating the protocol and hardware modules and the pilight program. This means that when you compile and install pilight the regular way, it only contains support for:
- Protocols
-- raw
-- pilight-firmware
- Hardware
-- none
-- gpio

This is the bare minimum for pilight to run on all platforms. When you want to add additional protocols or hardware modules you can then install them one by one:
Code:
apt-get install pilight-protocol-arctech_switch
apt-get install pilight-hardware-433lirc

This also adds the ability to upgrade protocols when new versions are released without having to wait for a new general pilight release:
Code:
apt-get upgrade pilight-protocol-arctech_switch

You then just restart pilight and the new version will be used.

The questions
1. Do you guys want modules as separate libraries and nothing compiled in?
2. Do you guys want to have all modules at a certain release point compiled into pilight and no separate modules?
3. Do you guys want a combination of both. So all modules are compiled into pilight, but when a (never version) of a module is installed as a library, pilight will use that version instead?
 
Reply
#2
1.yes, seperate packages for protocols and devices sounds awesome and would perfectly fit into debian sources
2.no
3.no

awesome work!
 
Reply
#3
I would advice against separating things. It won't make it easier for regular users and more advanced users already install the development branch from github. The current way of using ./setup.sh is good enough for me but it could be made more attractive/advanced (although I don't see how..., I've had an idea in the past but I forgot it).
 
Reply
#4
I'm more for option 3. Give the users the choice. That way, protocol creation is not limited to just pilight. E.g. meloen could distribute his smoke alarm protocols until pilight gets native support for them. Also, if a builtin protocol is bugging, we can simple disable it by adding a dummy overriding protocol as a library.
 
Reply
  


Possibly Related Threads...
Thread Author Replies Views Last Post
  simultaneous support for multiple hw modules curlymo 1 1,752 01-03-2014, 02:04 PM
Last Post: curlymo
  [Done] multiple protocols per device Martin 9 3,942 10-09-2013, 12:02 PM
Last Post: curlymo

Forum Jump:


Browsing: 1 Guest(s)