• 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
pilight 8.0
#1
In respons to your requests i'm planning to release a pilight version 8.0 based on all commits until i started backporting from rewrite. That means that the last commit into pilight 8.0 will be 1c5c59b1bb451f6abdeb493371ba606595c6a55b on the 10th of july this year.

Commits that will be excluded:
Code:
c24b71904c8d62141a5c91ceb2d60de5f145a0c0    Readded Rev
c294a8aac49b8d262ccd1fd0f5aff8dcc4c89e45    Fixed webserver SSL compilation
aff15b04ab4d3730e4a695441ec8737ba2dec7b8    Enable webserver SSL using our internal polarssl
447917664994468b012d99ab3102163d32b50426    Forgot to commit new essential updates
96f25fdae2b0e78e5ab860f429e01d86608b4293    Reverted aff15b04ab4 becuase it was clearly unstable
953bb8511b43b62197df693f5b6beaf6a79d1e1a    Webserver HTTPS should be off by default again
007f424e76500667924e26a791d7a9b4c183dfdc    First version of Razberry Z-Wave support
e70b92cf86a76dddd9a478c172ee6bec03bde8f3    Also add OpenZWave library
9d95e92abd610780d0a60dbecf1d9e4a8fb6283a    Properly exclude Z-Wave when turned off
097d212f46a837232882441ee18612e672c8c78e    Readded Radxa support
d207c3edb70bd1af290fe0bc1941f170990cb4e1    Fixed radxa module
508428f6f87d06086ebf66090569a75625585f11    Added missing radxa files
fd20514c488c4338f5d279239dc8187c2852fda4    Add support for Z-Wave dimmers and parameter settings
a8b12ea1a757601eda4f2c575474ba2b37849049    Small radxa module fix
46405634af89d81c4e4755b7f17a33333cec16e1    Allow actions based on received data
64a06084fea00e6e403286b718bfe3e9f7f94ba2    Intermediat fix for PHP parsing
cbcdb272d1463af3408fa52739a0a033b620141a    Improved PHP parsing
a81e71c3916ce0f76cedb0a362474e232fe9ea5b    Embed basic PHP parser
162389a60d1bed30a4f6fc644fdc82d4fa8d1935    Revert commit a81e71c391
af14308e11f867eec51e5981b3bc0b637cbde76b    Fixed memory leak in webserver PHP parsing
b35b96af84f4a329062f6d8663ba3fc5d74d22d9    Removed PHP support altogether
0032183e86b9147b4609f9fdd20320fcb56be41e    Fixed zwave hardware module

Any comments?
 
Reply
#2
We are waiting for release Smile
 
Reply
#3
Nice to read.

I will upgrade my terrarium with pilight 8.0 as soon as possible.
With the whole rules in the automation I can then check the release thoroughly!

Are there changes in the config.json between 7.0 and 8.0?

If so the documentation would need to be updated also.
Otherwise the forum will be flooded with configuration requests...
Terrarium:  RPi Model B Rev 2 / pilight 8.1.2 / stretch
Aquarium: RPi Model B Plus Rev 1.2 / pilight 8.0.6 / jessie
 
Reply
#4
Have you checked manual.pilight.org lately? Meaning, i'm working on it.
 
Reply
#5
indeed i did not - sorry..
Terrarium:  RPi Model B Rev 2 / pilight 8.1.2 / stretch
Aquarium: RPi Model B Plus Rev 1.2 / pilight 8.0.6 / jessie
 
Reply
#6
I understand that Oregon and somfy protocol support are an issue for you (despite them running without known issues AFAIK).
Is it possible to add the protocols philips hue (okay Pr #216 has some minor glitches but once it is integrated into development an additional PR will be issued ....) and gw isds07 and dev GUI contact protocol support ?

Gesendet von iPhone mit Tapatalk
 
Reply
#7
Everything is open for discussion. The whole reason i opened this thread.

- Never heard that Oregon and Somfy are running without issues now. I just heard that they were under development and nearly stable. Also, AFAIK we still need to figure how to properly receive those protocols.

- Bridge, the discussion why we need the bridge in the first place and just can't switch to the Zigbee hasn't been properly resolved in that PR. And why wait for an additional PR?

- #PR212 should be clear. That PR is not ok for merge according to the contribution guide.

- #PR337 same reason. Just not ready for merging.
 
Reply
#8
(09-20-2017, 06:23 AM)curlymo Wrote: - Never heard that Oregon and Somfy are running without issues now. I just heard that they were under development and nearly stable. Also, AFAIK we still need to figure how to properly receive those protocols.
Both protocols are deviating to a certain extend from the assumptions made for standard pilight pulsetrains, in particular with regard to the handling of:
- wakeup sequences for devices (somfy),
- protocol headers (somfy and oregon),
- data pulse durations in the range of footer values (somfy)
- footer pulses (oregon),
- number of repetitive pulsetrains (oregon),
- repetitive sequence of separation pulses (instead of single footer pulse) between repetitive pulsetrains (oregon)
- different pulsetrains for 1st and repetitive pulsetrains (somfy)
- no repetitive pulsetrains and no single header/footer pulse duration (oregon 3.0)

I am using COCO switches, QUIGG GT_7000 switches and dimmers, Brennstuhl switches, Philips Hue bulbs, SOMFY shutters, OREGON weather devices, TFA weather devices, 3 Raspberry Pi with UUID extension for more than a year.

I do consider that the code base for V7.0/V8.0 differs from the rewrite branch, and that branch requires a new approach for those protocols anyway, thus i simply proposed to go ahaed some time ago, in order to gain more experience, but I am not insisting on it.

(09-20-2017, 06:23 AM)curlymo Wrote: - Bridge, the discussion why we need the bridge in the first place and just can't switch to the Zigbee hasn't been properly resolved in that PR. And why wait for an additional PR?
(1) This subject was discussed on github already.
I am using (1) dedicated Hardware, (2)Windows & (3)iOS App to control my Hue bulbs, they all require the Bridge.
Main reason for getting this PR implemented is to gain access to the Philips Hue subsystem and to relay this interaction to the aforementioned devices.

(2) I have implemented the required modifications on my wo-rasp git repository, for the pilight repository i do wait for acceptance of the original PR and will issue my motifications thereafter.

(09-20-2017, 06:23 AM)curlymo Wrote: - #PR212 should be clear. That PR is not ok for merge according to the contribution guide.
I have not asked for the GE Chip protocol to be accepted (although it is part of my test-dev branch)

(09-20-2017, 06:23 AM)curlymo Wrote: - #PR337 same reason. Just not ready for merging.
Hmmm, I forgot to add #PR335 (Contact GUI), due to GUI implementation for contact protocol is an issue pending since 2014.
#PR337 will benefit from #PR335.

@loggisch described the protocol, a wiki page does exist for gs iwds07 devices ......, he confirmed that the combintion of both is working for him.
 
Reply
#9
Quote:Both protocols are deviating to a certain extend from the assumptions made for standard pilight pulsetrains, in particular with regard to the handling of.
I we are going to proceed on this i need dedicated coorperation, especially because this is a core change of pilight that needs to be implemented well (as described in the hue PR). If you are ok with it, i want to suggest we discuss this on IRC the upcoming weeks? If you, can you sent me an email so we can discuss details?

I the meantime i opened a PR that shows what my vision on the core changes should be.

Quote:This subject was discussed on github already.
I'm ok with implementing the protocol, but i do insist on some changes also proposed on github. So let's discuss this further there. Maybe @ma-ca can give you access to his repo so you can both work on the PR?

Quote:#PR212
I though you meant this PR as well. My mistake Smile

Quote:#PR335
Still, not all issues are resolved with that PR.
https://github.com/pilight/pilight/pull/...r104325775

Quote:#PR337
Still not ready to be merged according to the contribution guideliness.

In general, i do not monitor PR's. If contributors think they are finished with the PR, they can notifiy me. If i have left comments, i forgot about the PR until the comments have been answered or resolved. If i never get a response, then the PR will never get merged.

Take my PR into libuv as an example:
https://github.com/libuv/libuv/pull/1040

I have been working on that one for about 9 months, regularly polling the dev team for reviews and comments until it was merged.
 
Reply
#10
A design decision to move from pthread to libuv is one topic and I would keep that to the rewrite branch.
Another subject is protocol compatibility and on this subject we face in my opinion two to four or more challenges, mainly :
1. Handling of Header-/Footerless protocols
2. Wrapper Interface for "devices belonging to one family" using the same protocol but different pulse durations (for example different clock frequencies)
3. Handling of Pre-/Post protocol pulses (to wakeup a device, to separate pulsetrains, ...)
4. Definition of oscillator clock frequency (and its recovery from received pulse trains)

In particular clock recovery will help to work with flank detection logic instead of pulse durations. What may be required for this to work reliably is the creation of a daemon to be added to the gpio driver, and thus it is a hardware specific addition, may-be to the wiringX libraries as they are Hardware/OS dependent anyway (move clock time stamping of a received I/O state change from gpio.c to the new daemon).

In my opinion the approach of using priority settings for time critical code parts in user mode will always be critical.
Once we have appropriately solved this, various approaches can be used (for example libuv) to present received streams to all user defined processes interested.

Gesendet von iPhone mit Tapatalk
 
Reply
  


Possibly Related Threads...
Thread Author Replies Views Last Post
  pilight bugs Ascenion 1 283 03-23-2020, 06:29 PM
Last Post: curlymo
  [Solved] pilight service crashing on first webserver access after reboot VrahoK 20 2,287 12-21-2019, 09:46 AM
Last Post: curlymo
  pilight-control modify values coolinx 16 1,986 11-13-2019, 08:02 PM
Last Post: curlymo
  Bug: double free or corruption in pilight-send blackzombie 12 1,632 10-07-2019, 08:15 PM
Last Post: blackzombie
  [Fixed] High CPU usage when pilight usb nano disconnects DieterK 1 617 08-13-2019, 05:43 PM
Last Post: curlymo
  pilight Nano USB interface curlymo 228 125,425 07-10-2019, 06:14 PM
Last Post: curlymo
  problems compiling pilight on Odroid C2 WitchDoctor 101 20,020 03-14-2019, 09:01 PM
Last Post: curlymo
  pilight 8 what chages for custom protocols? polo 11 4,729 02-15-2019, 06:22 PM
Last Post: polo
  pilight-debug shows nothing minhdomanh 3 1,110 10-18-2018, 07:01 AM
Last Post: felfert
  pilight-send and pilight-daemon DieterK 0 969 06-20-2018, 12:44 AM
Last Post: DieterK

Forum Jump:


Browsing: 1 Guest(s)