Original Plug-in Recent Updates

[mitch7391]

With Luke Rhodes updating the original plug-in after so long, will this plug-in also be getting the same updates? Excuse my ignorance on GitHub and all this stuff; I am not sure if with this being a fork if it gets those updates from his or if it requires work on your part to apply the same updates. Any way keep up the good work and thanks! :)

[kiwi-cam]

I’ve been watching the changes there closely too and plan on doing some testing when I’m home from holiday and the changes settle down.

I don’t know about @AlexanderBabel but the way I see it, it’ll go one of two ways:

1. If Luke replicates all the functionality we have, I may abandon this fork until we find other functions to add.
2. If there’s still value in this fork I’ll add Pull Requests to merge Luke’s improvements here.

I’m taking a wait and see approach for now.

[mitch7391]

No rush and enjoy your holidays! My only worry long term is with how long it was abandoned for last time due to other projects he is working on, that it could happen again haha but very happy to see what you two decide :)

[AlexanderBabel]

@kiwi-cam I agree on your view.

For me it looks like Luke is slowly starting to work again on the project. So I guess the best approach would be then to do pull request in the main project with the features from this fork. (I guess we need to hand pick the improvements we've made, otherwise the PR would be too big as you saw it in your try earlier.)

But as you said we should wait how's it going with the frequency of his updates.

Another approach would be to work directly on the main project with him together, like what you are currently doing in this fork. So that at least one person is hopefully maintaining the project. But I don't know his opinion on this. So it's just an idea.@kiwi-cam I agree on your view.

For me it looks like Luke is slowly starting to work again on the project. So I guess the best approach would be then to do pull request in the main project with the features from this fork. (I guess we need to hand pick the improvements we've made, otherwise the PR would be too big as you saw it in your try earlier.)

But as you said we should wait how's it going with the frequency of his updates.

Another approach would be to work directly on the main project with him together, like what you are currently doing in this fork. So that at least one person is hopefully maintaining the project. But I don't know his opinion on this. So it's just an idea.

[mitch7391]

Sounds like a good idea, sounds a lot easier to merge back into his and help him keep it maintained (if he is cool with that). I guess I’m worried it’s look like one bulk update and cleanup before another long break again. So hopefully you guys can become maintainers on his one, as you have been keeping the plug-in alive in my opinion!

[kiwi-cam]

I've had some success today. I've merged @lprhodes changes in to a new branch here to simplify an eventual Pull Request back to the upstream branch - fewer differences to merge.

With just a couple of tweaks everything seems to be working. I'd like to monitor and, all going well, I'll then merge the changes into our master and create a Pull Request back to the upstream branch.

If anyone would like to do some testing too, the branch can be installed using: npm install -g git+https://github.com/AlexanderBabel/homebridge-broadlink-rm#kiwi-cam-mergetest.

I did have a couple of issues:

1. When reverting versions after a failed attempt I had to uninstall and re-install - installing over the top failed.
2. I got the following error in the logs which I followed the steps noted to resolve it but the path for me was a symlink so I had to find the actual file path using ls -al /path/to/node:

Jan 09 11:06:39 homebridge[25722]: [Broadlink RM] Broadlink RM won't detect device failures due to a permissions issues with "net-ping". Jan 09 11:06:39 homebridge[25722]: To fix: Jan 09 11:06:39 homebridge[25722]: 1. Run "which node" to determine your node path. Jan 09 11:06:39 homebridge[25722]: 2. Run "sudo setcap cap_net_raw+ep /path/to/node". Jan 09 11:06:39 homebridge[25722]: Note: Replacing /path/to/node with the path you found in the first step.

If you're keen, try it out and let me know how it goes.

[lprhodes]

FYI this weekend I shall be making the changes needed to allow people to add new accessories (via npm) without needing to adjust the core plugin.

I’m also in the process of moving the code for home ridge-broadlonk-rm and homebridge-platform-helper to Typescript.

On Thu, 9 Jan 2020 at 09:46, Cameron notifications@github.com wrote:

I've had some success today. I've merged @lprhodes https://github.com/lprhodes changes in to a new branch here to simplify an eventual Pull Request back to the upstream branch - fewer differences to merge.

With just a couple of tweaks everything seems to be working. I'd like to monitor and, all going well, I'll then merge the changes into our master and create a Pull Request back to the upstream branch.

If anyone would like to do some testing too, the branch can be installed using: npm install -g git+ https://github.com/AlexanderBabel/homebridge-broadlink-rm#kiwi-cam-mergetest .

I did have a couple of issues:

1. When reverting versions after a failed attempt I had to uninstall and re-install - installing over the top failed.
2. I got the following error in the logs which I followed the steps noted to resolve it but the path for me was a symlink so I had to find the actual file path using ls -al /path/to/node:

Jan 09 11:06:39 homebridge[25722]: [Broadlink RM] Broadlink RM won't detect device failures due to a permissions issues with "net-ping". Jan 09 11:06:39 homebridge[25722]: To fix: Jan 09 11:06:39 homebridge[25722]: 1. Run "which node" to determine your node path. Jan 09 11:06:39 homebridge[25722]: 2. Run "sudo setcap cap_net_raw+ep /path/to/node". Jan 09 11:06:39 homebridge[25722]: Note: Replacing /path/to/node with the path you found in the first step.

If you're keen, try it out and let me know how it goes.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/AlexanderBabel/homebridge-broadlink-rm/issues/64?email_source=notifications&email_token=AABHZLOFWQODU6BXJISHSPTQ4ZJT5A5CNFSM4KCH74V2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIOIMDY#issuecomment-572294671, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABHZLITDBUBSYV24DR34S3Q4ZJT5ANCNFSM4KCH74VQ .

--

Thanks

--

Luke Rhodes

iPhone, iPad, Mac, and Web Developer

http://lukerhodes.net

[mitch7391]

@kiwi-cam I just gave your test fork a go and it would not install. I got the following errors:

pi@raspberrypi:~ $ sudo npm install -g git+https://github.com/AlexanderBabel/homebridge-broadlink-rm#kiwi-cam-mergetest npm ERR! code 128 npm ERR! Command failed: git clone --depth=1 -q -b kiwi-cam-mergetest https://github.com/AlexanderBabel/homebridge-broadlink-rm.git /root/.npm/_cacache/tmp/git-clone-42ba76e9 npm ERR! fatal: could not create leading directories of '/root/.npm/_cacache/tmp/git-clone-42ba76e9': Permission denied npm ERR!

npm ERR! A complete log of this run can be found in: npm ERR! /root/.npm/_logs/2020-01-10T05_18_23_035Z-debug.log

Should I just wait until the weekend to see how Luke's project goes?

[kiwi-cam]

Sorry @mitch7391, that error is familiar. That's a permissions issue with npm and git. Basically it doesn't work with sudo so you'll need to get all the folders and permissions right when not using sudo.

Up to you :-)

[mitch7391]

I tried without sudo as well and got a bunch of errors. Wonder if I did something different setting up the RPi3 I’m using now. Are you able to point me in the right direction to what id need to do please?

[kiwi-cam]

I had the same thing at one point and decided that the fix was to get npm to work without sudo - rather than getting git to work for sudo.

First I'd suggest running

sudo npm config get prefix
echo $NODE_PATH
echo $PATH

And making notes of the results so you've got the option of rolling back these changes if you want/need.

For me, I found that my account and sudo installed global npm modules in different paths. Mine installed in /usr/lib/node_modules so I run the below commands to make this the setting: sudo npm config set prefix /usr I also updated some env variables. NODE_PATH has the two places I've seen node modules installed (although the first should be used from now on based on first command). I also added the new path to the PATH variable.

export NODE_PATH=/usr/lib/node_modules:/opt/node/lib/node_modules
export PATH="/usr/lib:$PATH"

Hopefully that helps. I've been running the merged version for 5 days without any issues but I'd love to have someone else try it too and confirm.

[mitch7391]

@kiwi-cam thanks for the suggestions! I will give them a go after work tonight and then I can start testing the merged version for you :)

[mitch7391]

@kiwi-cam I just tried following what you advised and pretty sure I did it wrong, this is what I first received:

I then followed the other commands, which may not be correct based on what I saw?

I then tried to install the test version with both 'sudo' and without:

[mitch7391]

Also should I be reverting anything I did just then? (as I do not know what I am doing lol)

[kiwi-cam]

Looks like your prefix was set correctly from the start - unlike mine.

Those errors are permissions on /usr/lib/node_modules. I use the default pi account which is the owner of the /usr/lib/node_modules directory. We're going way off topic here but could you try the following:

cd /usr/lib/node_modules
ls -al

I have pi as the owner and 755 access (pi read/write, groups and everyone read and execute) to this directory. Depending on your permissions you can use these commands: Change the owner to pi (and group to pi): sudo chown -R pi:pi /usr/lib/node_modules Change the permissions to 755: sudo chmod -R 755 /usr/lib/node_modules

[kiwi-cam]

Also, I wouldn't worry about reverting the changes since your prefix was already set to that value.

[mitch7391]

Thank you so much for taking the time to go through that @kiwi-cam, I know it was way off topic but hopefully it helps anyone else with similar problem! I have now installed the merge test and will see how it goes :)

[mitch7391]

Only have had a chance for some quick testing before night shift, but devices seem to be working fine. One thing I noticed was that my tv feedback ping was no longer spamming my Homebridge logs (probably one of the changes?). I will have to take the time to read through the changes compiled to know what’s really new.

@lprhodes with the amount of changes that have occurred recently, will there be an update to the readme file and examples page eventually? Your examples page and readme are one of the most detailed Iv seen on any plugin, so it would be cool to see the new stuff detailed on it (if not already) :)

[lprhodes]

Hey @mitch7391 I certainly shall be updating the docs once shortly :)

[mitch7391]

Nice :) I don’t envy that job lol

[kiwi-cam]

@mitch7391 I had issues with the ping too. Do you by chance ping the TV by hostname? Could you try using IP address? This workaround seems to have worked for me.

[mitch7391]

I have always had it use the IP address instead of the host name. The feedback is correct if I use the tv remote and then check HomeKit, it just doesn’t show the constant ping states in Homebridge logs (which I’m not fussed about haha).

[kiwi-cam]

Ah. Maybe that’s the bug... I’ll take a look into it next week.

[mitch7391]

@kiwi-cam just noticed that occasionally the ping is shown in my logs, but quite randomly. I have it on a ping frequency of 2s. Had no pings in the log after the merge update and now randomly I get bursts of it like this.

`[1/19/2020, 8:59:21 PM] [Broadlink RM] TV getSwitchState: true

[1/19/2020, 8:59:39 PM] [Broadlink RM] TV getSwitchState: true

[1/19/2020, 8:59:49 PM] [Broadlink RM] TV getSwitchState: true

[1/19/2020, 9:00:12 PM] [Broadlink RM] TV getSwitchState: true

[1/19/2020, 9:00:18 PM] [Broadlink RM] TV getSwitchState: true

[1/19/2020, 9:00:26 PM] [Broadlink RM] TV getSwitchState: true

[1/19/2020, 9:00:27 PM] [Broadlink RM] TV getSwitchState: true

[1/19/2020, 9:00:41 PM] [Broadlink RM] TV getSwitchState: true

[1/19/2020, 9:00:56 PM] [Broadlink RM] TV getSwitchState: true

[1/19/2020, 9:00:57 PM] [Broadlink RM] TV getSwitchState: true

[1/19/2020, 9:01:05 PM] [Broadlink RM] TV getSwitchState: true

[1/19/2020, 9:01:06 PM] [Broadlink RM] TV getSwitchState: true

[1/19/2020, 9:01:14 PM] [Broadlink RM] TV getSwitchState: true

[1/19/2020, 9:01:15 PM] [Broadlink RM] TV getSwitchState: true

[1/19/2020, 9:01:25 PM] [Broadlink RM] TV getSwitchState: false

[1/19/2020, 9:01:27 PM] [Broadlink RM] TV getSwitchState: true

[1/19/2020, 9:01:39 PM] [Broadlink RM] TV getSwitchState: true

[1/19/2020, 9:01:53 PM] [Broadlink RM] TV getSwitchState: true

[1/19/2020, 9:01:54 PM] [Broadlink RM] TV getSwitchState: true

[1/19/2020, 9:02:06 PM] [Broadlink RM] TV getSwitchState: true

[1/19/2020, 9:02:21 PM] [Broadlink RM] TV getSwitchState: true

[1/19/2020, 9:02:27 PM] [Broadlink RM] TV getSwitchState: true

[1/19/2020, 9:02:30 PM] [Broadlink RM] TV getSwitchState: true

[1/19/2020, 9:02:39 PM] [Broadlink RM] TV getSwitchState: true

[1/19/2020, 9:02:47 PM] [Broadlink RM] TV getSwitchState: true

[1/19/2020, 9:02:57 PM] [Broadlink RM] TV getSwitchState: true

[1/19/2020, 9:03:01 PM] [Broadlink RM] TV getSwitchState: true`

Weird that I had a false returned in there, as my TV was on at the time. Still have not noticed any issues with my other devices so far.

[kiwi-cam]

Hi @mitch7391. I've confirmed that what you're logging isn't related to the dns resolution issue I've been having... but I've also been unable to recreate the issue you're having.

Do you see issues with the status of the TV updating if the TV is turned on using the remote?

Also, I'm not sure what you're seeing in the logs is the ping. getSwitchState is just something querying the "switch" state - e.g. loading up the Home app and viewing the device status. Is there anything else happening at the time that you see this in the logs that might be querying devices?

[mitch7391]

@kiwi-cam hmm interesting... Yeah the status of the TV still correctly updates if I use the remote. I was always under the impression that the getSwitchState was done at the frequency of the ping you set; so my bad if I led you down the wrong path there.

I am not seeing anything unusual in my logs or different except for the lack of the getSwitchState which used to appear every 2s. I do now have the following warning, but I think it is unrelated and may be due to updating Node.JS to 12.14.1 or due to tuya-lan plugin (two things I have changed recently after this merge):

Jan 21 15:51:20 raspberrypi homebridge[7081]: HAP Warning: Characteristic 00000025-0000-1000-8000-0026BB765291 not in required or optional characteristics for service 000000D8-0000-1000-8000-0026BB765291. Adding anyway.

Otherwise nothing else seems off that I can see.

[kiwi-cam]

I might've just found the reason for the TV status being a bit strange when ping based and the HAP Warning message. I copied the updated ping code from the switch accessory in the original fork but it uses a different characteristic name (On vs Active). could you try running npm install -g git+https://github.com/AlexanderBabel/homebridge-broadlink-rm#kiwi-cam-mergetest and see if that fixes the issues?

[mitch7391]

@kiwi-cam I just installed your latest test. I notice that I seem to get this warning as homebridge reboots, I am not sure if it was there before sorry.

[1/23/2020, 1:19:08 PM] Warning: skipping plugin found at '/usr/local/lib/node_modules/homebridge-broadlink-rm-tv' since we already loaded the same plugin from '/usr/lib/node_modules/homebridge-broadlink-rm-tv'.

I also notice now that the state in homekit of the TV does not change unless I close and open homekit again; this was not happening before. E.g turn off TV with remote and watch homekit, TV is still on in homekit until I exit and and re-open it.

[mitch7391]

In case I have set up anything wrong or outdated with with my config for the broadlink or the TV setup, here it is:

{ "platform": "BroadlinkRM", "name": "Broadlink RM", "hideScanFrequencyButton": false, "hideLearnButton": false, "hideWelcomeMessage": true, "accessories": [ { "name": "TV", "type": "tv", "pingIPAddress": "192.168.0.161", "pingFrequency": 2, "pingIPAddressStateOnly": true, "data": { .....

I have left the data section out so as not to spam the post with unnecessary info.

[mitch7391]

Also the get switch state is back to just randomly populating the homebridge log after a while.

[1/23/2020, 1:36:49 PM] [Broadlink RM] TV getSwitchState: true [1/23/2020, 1:43:41 PM] [Broadlink RM] TV getSwitchState: true [1/23/2020, 1:43:53 PM] [Broadlink RM] TV getSwitchState: true [1/23/2020, 1:44:04 PM] [Broadlink RM] TV getSwitchState: true [1/23/2020, 1:44:17 PM] [Broadlink RM] TV getSwitchState: true [1/23/2020, 1:44:29 PM] [Broadlink RM] TV getSwitchState: true [1/23/2020, 1:44:41 PM] [Broadlink RM] TV getSwitchState: true [1/23/2020, 1:44:56 PM] [Broadlink RM] TV getSwitchState: true

[kiwi-cam]

[1/23/2020, 1:19:08 PM] Warning: skipping plugin found at '/usr/local/lib/node_modules/homebridge-broadlink-rm-tv' since we already loaded the same plugin from '/usr/lib/node_modules/homebridge-broadlink-rm-tv'.

This is probably related to the earlier changes with the paths. You've got the plugin installed twice. Check /usr/local/lib/node_modules/homebridge-broadlink-rm-tv and /usr/lib/node_modules/homebridge-broadlink-rm-tv and delete the oldest one.

The issue you're describing with the TV status is similar to what I was seeing before yesterday's changes. So I suspect homebridge has loaded the older version of the plugin.

[mitch7391]

@kiwi-cam thanks for pointing this out (I swear I am learning as I go haha)... It seems all of my plugins live in /usr/lib/node_modules and the merge test (the very latest one) is by itself in /usr/local/lib/node_modules. I deleted the node_modules directory out of /usr/local/lib and tried to install the merge test again; however it again installed back in /usr/local/lib/node_modules by itself again.

[kiwi-cam]

That's really odd... especially after it was all working.

Has the output from:

sudo npm config get prefix
echo $NODE_PATH
echo $PATH

changed at all?

[mitch7391]

I am wondering if maybe I did something wrong with that in the first place and didn't notice. Not sure if echo $NODE_PATH was supposed to return something? As it didn't the first time either.

[kiwi-cam]

Sorry - this is getting beyond my knowledge of node. Did you run the git install with the -g switch? I can't see where it's getting the /usr/local/lib/node_modules reference. Maybe try running npm config get prefix (without sudo). See if the current user gets a different value.

Or, maybe try setting NODE_PATH to where everything should be by running: export NODE_PATH=/usr/lib/node_modules

The dirty fix is to delete the directory /usr/lib/node_modules/homebridge-broadlink-rm-tv so it only has the git one to use.

[mitch7391]

I think we have it! Your mention of don't use 'sudo' for npm config get prefix made me realise I always put 'sudo' before my installs, but for your latest merge test I just copied and pasted your command without 'sudo' this time.

This time I installed your merge test command with sudo before it and it has updated the one in '/usr' instead of creating a new 'node_modules' in '/usr/local'.

Would you suggestion of executing export NODE_PATH=/usr/lib/node_modules fix the issue where I have two different install pathways for 'sudo' and no 'sudo'?

[mitch7391]

At the very least I should be in business with your merge test update :) and will know what to watch out for next time.

[kiwi-cam]

I have both normal and sudo install in /usr/lib/node_modules but there is probably a use case for having them separate. If you'd like to make them both the same just run npm config set prefix /usr (without sudo) so the prefix is the same for both.

I believe updating NODE_PATH is more related to finding the modules so probably won't change much for you.

[mitch7391]

That is exactly what I did as a test before you replied to see if it that worked. Then I would wait for your reply to tell me how to really do it lol awesome, I am happy with it this way as I wont make the mistake of installing in two places.

Also the merge test update has fixed the issue of the TV state not updating when using the remote. Am I supposed to be seeing the TV state in the log at the rate of my ping frequency like I used to before the merge? And I also notice my fishtank light controlled over the Broadlink is no returning a getSwitchState in my logs, when it never used to (not a big deal, just notice it started doing it with the merge test). Otherwise all looks good so far!

[mitch7391]

@kiwi-cam has something changed recently as suddenly in my logs I get this whilst the TV is on:

[2/6/2020, 7:11:17 PM] [Broadlink RM] TV pingCallback: state changed (device inactive) [2/6/2020, 7:11:17 PM] [Broadlink RM] TV getSwitchState: false [2/6/2020, 7:11:18 PM] [Broadlink RM] TV pingCallback: state changed (device active) [2/6/2020, 7:11:18 PM] [Broadlink RM] TV getSwitchState: true [2/6/2020, 7:11:59 PM] [Broadlink RM] TV pingCallback: state changed (device inactive) [2/6/2020, 7:11:59 PM] [Broadlink RM] TV getSwitchState: false [2/6/2020, 7:12:00 PM] [Broadlink RM] TV pingCallback: state changed (device active) [2/6/2020, 7:12:00 PM] [Broadlink RM] TV getSwitchState: true [2/6/2020, 7:12:29 PM] [Broadlink RM] TV pingCallback: state changed (device inactive) [2/6/2020, 7:12:29 PM] [Broadlink RM] TV getSwitchState: false [2/6/2020, 7:12:30 PM] [Broadlink RM] TV pingCallback: state changed (device active) [2/6/2020, 7:12:30 PM] [Broadlink RM] TV getSwitchState: true [2/6/2020, 7:13:39 PM] [Broadlink RM] TV pingCallback: state changed (device inactive) [2/6/2020, 7:13:39 PM] [Broadlink RM] TV getSwitchState: false [2/6/2020, 7:13:40 PM] [Broadlink RM] TV pingCallback: state changed (device active) [2/6/2020, 7:13:40 PM] [Broadlink RM] TV getSwitchState: true [2/6/2020, 7:15:57 PM] [Broadlink RM] TV pingCallback: state changed (device inactive) [2/6/2020, 7:15:57 PM] [Broadlink RM] TV getSwitchState: false [2/6/2020, 7:15:59 PM] [Broadlink RM] TV pingCallback: state changed (device active) [2/6/2020, 7:15:59 PM] [Broadlink RM] TV getSwitchState: true [2/6/2020, 7:16:47 PM] [Broadlink RM] TV pingCallback: state changed (device inactive) [2/6/2020, 7:16:47 PM] [Broadlink RM] TV getSwitchState: false [2/6/2020, 7:16:48 PM] [Broadlink RM] TV pingCallback: state changed (device active) [2/6/2020, 7:16:48 PM] [Broadlink RM] TV getSwitchState: true [2/6/2020, 7:18:05 PM] [Broadlink RM] TV pingCallback: state changed (device inactive) [2/6/2020, 7:18:05 PM] [Broadlink RM] TV getSwitchState: false [2/6/2020, 7:18:07 PM] [Broadlink RM] TV pingCallback: state changed (device active) [2/6/2020, 7:18:07 PM] [Broadlink RM] TV getSwitchState: true [2/6/2020, 7:20:58 PM] [Broadlink RM] TV pingCallback: state changed (device inactive) [2/6/2020, 7:20:58 PM] [Broadlink RM] TV getSwitchState: false [2/6/2020, 7:20:59 PM] [Broadlink RM] TV pingCallback: state changed (device active) [2/6/2020, 7:20:59 PM] [Broadlink RM] TV getSwitchState: true

[mitch7391]

The TV is not changing state during this time...

[kiwi-cam]

No, no changes that I'm aware of. On the 30 Jan I did merge the branch we were using for testing into the Github master and delete our branch - but no files were changed from the branch we used.

The timings on these look random. These aren't just random ping packets being dropped are they? If you see this happen again, could you run a ping to the TV and see if you get any packet loss?

[mitch7391]

@kiwi-cam sorry for the delayed response. Strange one indeed, I notice randomly it will drop in a false whilst the TV is on, not a big deal just thought I would bring it up. It looks like when I ping it from command I am occasionally getting a time out; so looks like it would be nothing related to the plug-in.

C:\Users\Mitchell>ping 192.168.0.161 -t

Pinging 192.168.0.161 with 32 bytes of data: Reply from 192.168.0.161: bytes=32 time=86ms TTL=64 Reply from 192.168.0.161: bytes=32 time=108ms TTL=64 Request timed out. Reply from 192.168.0.161: bytes=32 time=64ms TTL=64 Reply from 192.168.0.161: bytes=32 time=79ms TTL=64 Reply from 192.168.0.161: bytes=32 time=92ms TTL=64 Request timed out. Reply from 192.168.0.161: bytes=32 time=52ms TTL=64 Reply from 192.168.0.161: bytes=32 time=67ms TTL=64 Reply from 192.168.0.161: bytes=32 time=79ms TTL=64 Reply from 192.168.0.161: bytes=32 time=95ms TTL=64 Reply from 192.168.0.161: bytes=32 time=113ms TTL=64 Reply from 192.168.0.161: bytes=32 time=18ms TTL=64 Reply from 192.168.0.161: bytes=32 time=242ms TTL=64 Reply from 192.168.0.161: bytes=32 time=46ms TTL=64 Reply from 192.168.0.161: bytes=32 time=63ms TTL=64 Reply from 192.168.0.161: bytes=32 time=80ms TTL=64 Reply from 192.168.0.161: bytes=32 time=93ms TTL=64 Reply from 192.168.0.161: bytes=32 time=8ms TTL=64 Reply from 192.168.0.161: bytes=32 time=16ms TTL=64 Reply from 192.168.0.161: bytes=32 time=46ms TTL=64 Reply from 192.168.0.161: bytes=32 time=55ms TTL=64 Reply from 192.168.0.161: bytes=32 time=3ms TTL=64 Reply from 192.168.0.161: bytes=32 time=85ms TTL=64 Reply from 192.168.0.161: bytes=32 time=1ms TTL=64 Request timed out. Reply from 192.168.0.161: bytes=32 time=189ms TTL=64 Reply from 192.168.0.161: bytes=32 time=101ms TTL=64 Reply from 192.168.0.161: bytes=32 time=119ms TTL=64 Reply from 192.168.0.161: bytes=32 time=22ms TTL=64 Reply from 192.168.0.161: bytes=32 time=27ms TTL=64

[mitch7391]

And back on topic of the merging, now that it is merged do we have a read-me for all the added changes and examples of changes to config? Or is this something for Luke to take on when he gets time?

[mitch7391]

@kiwi-cam it has been a while since I focused on this, but where did we get with it all? Is Luke going to be maintaining the original plugin or are we better sticking with this fork (which is obviously maintained more regularly)?