The following warnings occurred:
Warning [2] count(): Parameter must be an array or an object that implements Countable - Line: 895 - File: showthread.php PHP 7.3.14-1~deb10u1 (Linux)
File Line Function
/showthread.php 895 errorHandler->error



  • 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:
  • 1 Vote(s) - 5 Average
  • 1
  • 2
  • 3
  • 4
  • 5
pilight v8.0 - Current work in progress
#1
I though it's maybe a good idea to tell you all what is happening with the project since not much activity can be seen on github currently.

The whole pilight internals are being rewritten to incoorporate the current features and improved functionality.

Internal event driven actions
Since the beginning of pilight, all events were communicated through specific function calls that were too much intertwined. For example, whenever the configuration was updated, a function was called evaluating all events, and a function was called to update the webserver. So for every new code that relied on config updates, a new function call had to be added in the pilight core.

The new event driven approach overcomes this by implementing a producer/consumer pattern. So the config update functionality now triggers the REASON_CONFIG_UPDATE event. On the other side various parts of pilight react on this event. So the core doesn't have to be changed when new functionality is released.

Threadpool
Since the beginning of pilight, all parallel code was run in a separate thread. This could lead to over 20 threads in complex setups. The new pilight code uses a threadpool. Functions are added to the threadpool awaiting execution and a fixed number of thread (workers) will execute them in parallel. pilight will dynamically add new workers when needed and remove them when they are idle for too long. There will never be more workers than there are number of cores.

Centralized socket handling
Since the beginning of pilight, all sockets communication was implemented on its own. Because, pilight uses non-blocking sockets, each implementation also used its own select statement to wait for events. The new approach uses a centralized socket handling library that processes all sockets at once. So all select statements were reduced to just one which grealy reduces resources. Socket events are also communicated in this library as events e.g. EV_SOCKET_SUCCES, EV_CONNECT_SOCKET, EV_READ, EV_WRITE.

Custom webserver implementation
The latest webserver implementation used by pilight (Mongoose) had some big limitations:
- SSL could not be easily ran on PolarSSL but only on OpenSSL.
- Adapting Mongoose to use a centralized socket pool was quite impossible.
- Adapting Mongoose to use the threadpool was quite impossible.
- Mongoose had a big overhead in functionality already present in pilight.

I thereby decided to drop Mongoose and created my own webserver (by reusing some of Mongoose and others code). This new webserver perfectly fits the new pilight codebase and also implements SSL by default.

Storage independent configuration
The pilight configuration has been rewritten to fix the new pilight core and has become storage independent. This means that the storage backened is now a module. The current codebase still only implements JSON as the storage backened, but this can easily be any other file based a database storage. This also allows for longitudinal data storage. The new config is also ready to implement on-the-fly config editing (through an enhanced API).

Respect UUID for all types of devices
In previous versions you could assign a UUID to a device so only a specific node would react on changes. This UUID setting only worked for relays and sensors. In the new version, the UUID setting will be respected for all devices. This means also with sending 433.92Mhz codes. This prevents interferens between nodes when sending 433.92Mhz.

Multiple AdHoc networks
In old versions you could only have one pilight adhoc network with auto-discovery. All other networks should be interconnected by using the IPTongueort settings. In the new version, multiple ad-hoc networks can be created with multiple pilight master daemons. This is done by naming each pilight daemon.
Code:
"name": "NAS"
Then you define that a specific daemon is a server or a client:
Code:
"adhoc-mode": "server"
or
Code:
"adhoc-mode": "client"

Then on the client you specify to which daemon the client should connect:
Code:
"adhoc-master": "NAS"

A client will only connect to the specific named server. Auto-reconnect will still work as in previous versions.

Using SSDP to control multiple pilight instances
In previous versions, only one pilight daemon could have its SSDP server enabled so it is auto-discoverable. In the new pilight version all master daemons will have its SSDP server enabled. This allows us to control each daemon more easily:
Code:
~ # ./pilight-control -d switch -s on
[ #]          server:port  name
[ 1]      10.0.0.141:5000  pi
[ 2]      10.0.0.140:57772 NAS
To which server do you want to connect?:

You can also directly control a specific named pilight instance by using the instance argument -I:
Code:
~ # ./pilight-control -d switch -s on -I NAS

Current status
The problem of these new functionality is that it affects everything in pilight. This also means that almost everything in pilight has to be rewritten. So all sockets, all threads, and all config related code. That's also the reason i can't commit intermediate code, because it all depends on each other.

Different visions on programming
So what i'm constantly trying to prevent is code like you can see here inside Domoticz (with all due respect, because i used their codebase as a reference for my ZWave implementation): https://github.com/domoticz/domoticz/blo...nZWave.cpp

Inside this Domoticz ZWave code, all storage calls, device types (e.g. switches, dimmers, thermostats), webserver calls, core calls are intertwined into one big spaghetti. Domoticz is a great piece of software, but in my vision of programming, the radical modulair approach is the holy grail, in contrast to what you see in Domoticz. That's also why pilight takes it (massively) slow.

What's Done
- Threadpool
- Eventpool
- Timerpool
- Webserver with SSL
- Storage independent config
- Centralized non-blocking IO.
- Protocols
- Ad-hoc Network
- Actions

Work in progress
Most work is done, currently busy testing everything locally and squashing bugs

Roadmap
I can't give any. I trying to combine a great new job and moving with the massive rewrite. But as you can see, i'm currently working on the details. Conclusion, pilight is alive and well, just not so online Smile
 
Reply
  


Messages In This Thread
pilight v8.0 - Current work in progress - by curlymo - 09-13-2015, 01:10 PM
pilight and iphone - by gwaag - 02-18-2018, 08:16 PM

Possibly Related Threads...
Thread Author Replies Views Last Post
  pilight for Raspbian Buster (raspberry pi 4) ? starob 30 7,120 39 minutes ago
Last Post: simanuel
  pilight switch node in node-red framp 0 228 06-24-2020, 10:01 PM
Last Post: framp
  pilight-control TML 13 890 05-27-2020, 07:51 AM
Last Post: curlymo
  API Requests by HTTP from other devices fore use in pilight scootermacro 2 397 05-10-2020, 08:19 AM
Last Post: scootermacro
  pilight-send seems successful but doesn't actually send RF signal ayeyebrazov 37 3,072 03-31-2020, 01:02 PM
Last Post: curlymo
  pilight 8.1.5 not working on Raspberry pi after reboot beejayf 4 838 03-08-2020, 12:14 AM
Last Post: beejayf
  pilight cpu usage possibly associated with noticeable sluggishness? hepcat72 4 892 01-28-2020, 08:02 PM
Last Post: hepcat72
  apt.pilight.org stable Release' is not signed. thomasol 2 939 01-23-2020, 11:34 PM
Last Post: thomasol
  pilight and SIGNALduino cc1101 Caleus 0 685 01-19-2020, 09:13 AM
Last Post: Caleus
  filter stopped working after update to pilight 8.1.5 zlin50 19 2,005 01-03-2020, 02:15 PM
Last Post: curlymo

Forum Jump:


Browsing: 1 Guest(s)