OpenNetHomeServer

[Mastiff]

Well, do you know when you are going to step that up, maybe to send two commands every minute? That's when fun stuff happens I think...

[krambriw]

I'll do that now and then we will see....but I think it is wise to have a few seconds between the commands

[krambriw]

Test is now running with two commands sent every minute with a 2 seconds delay in between each command

[Mastiff]

Yeah, it may. On my system I have a "send a command if none has been sendt to that zone for 5 minutes" setup, so they tend to group (since they are all sent for the first time when the sensors start coming in after a restart of EG). But usually there is a spread, since they are sent according to when a sensor comes in, and they are always spread out.

[Mastiff]

How is that new version working out for you? I suddenly discovered that there was nothing new from ONH after 4.30 last night, so I had to manually restart EG. It wasn't enough to restart the plugin and ONH with self-healing. Seems like it never stops. I'll have to add another one of those full restarts of EG with the egg timer, it seems.

[krambriw]

How is that new version working out for you?

Here it works since last discussion without any problems, it just runs, collects events & sends two commands every minute (very simple toggle commands, Nexa A1 and A2)

I suddenly discovered that there was nothing new from ONH after 4.30 last night, so I had to manually restart EG

In your newly sold house?

It wasn't enough to restart the plugin and ONH with self-healing

If Both ONH and the plugin is restarted and it doesn't help, where could next level of problem be sitting? In EG itself??? Obviously something was blocked since a restart of EG itself healed the problem

[Mastiff]

Here it works since last discussion without any problems, it just runs, collects events & sends two commands every minute (very simple toggle commands, Nexa A1 and A2)

Sounds good! I guess I'll have to try that version. Do you have it up?

In your newly sold house?

Yeah, that one... Still bugging me. The good thing is that since this is basically a redundancy system I don't think the buyer notice anything at all.

If Both ONH and the plugin is restarted and it doesn't help, where could next level of problem be sitting? In EG itself??? Obviously something was blocked since a restart of EG itself healed the problem

Yeah, something is wonky there for sure. But I've had that before, when a reset of the plug-in wasn't enough, EG had to be restarted. Maybe it's not the plugin or EG, but another plugin compounding it or even the initialization scripts that needs to be run for it to work?

[krambriw]

Do you have it up?

Yes, here it is http://krambriw.net/Release/OpenNetHome/
Just download and unzip into EG plugins folder

[krambriw]

Yeah, something is wonky there for sure

1) We know for sure that ONH can be stucked on the TCP port not being able to deliver events any more. This we have both seen a couple of times but it is not obvious how to reproduce the error. So right know we do not know how to provoke this to happen. This problem can only be sorted out and fixed by Stefan himself. Until this eventually happens, the only thing we can do is to kill and restart ONH when this state is detected.

So what are the differences in our systems?

2) I run EG in Windows (Win 10) in a from ONH separated environment with ONH running in a raspberry Pi and I have a very small configuration

3) You run both under Windows in a VMware host and you have probably a much larger configuration?

Could it be VMware that is holding some ip ports locked? It doesn't help just to stop the plugin but you have to restart EG????

[Mastiff]

Sorry I fell out again! I didn't get an E-mail warning about your post, and I have had to do so much here at the cabin, or rahter home... so I forgot to check in! Thanks, I'l implement the new version and see if anything gets better. I still have the occasional resets necessary (up to a couple of times a day, but for some reason usually at night) even with the heat system sends commented out.

And I guess the size of the configuration can be the thing, or that I run everything on one single VM. But the VMWare shouldn't matter here because of one thing: I never had any similar problems before this suddenly surfaced (and since I didn't note down when that happend I can't say precisely if it was before or after what changes), but I know for sure I haven't changed the VMWare version or the configuration of the VM. That has been the same for months. But there is of course another possibility, even if it's probably rather remote: I have my USB devices on an USB over TCPIP solution from the host to the VM (because I have had so much problems with the USB devices going AWOL when using direct USB from host to VM earlier). Still, that shouldn't affect this problem since the port for my USB over TCPIP system is 33000 while I'm using 8005 for the NHS setup.

Edit: OK, now you have managed to confuse me again... The file under Release is in a new format for me, .egplugin. Do you mean that I should put that in the NHS plugin directory, or what? And should I remove the .py stuff?

[krambriw]

OK, now you have managed to confuse me again...

OK, just take it easy

1) Be sure EG is running

2) Download and execute the .egplugin file (double-click on it). Follow instructions and install it

3) If you see nothing else, go into EG, add a plugin, select the new OpenNetHome server plugin and configure it

It should now be connected to ONH and running, events should come in

4) You can now disable the old one and it actions, eventually delete it completely once you think the new one is covering your needs

I do not know if you have seen the latest discussion at OpenNetHomeServer forum regarding MQTT? But I can tell you already that it is working not too bad. Events are coming in from ONH via MQTT and I can send commands to control devices like lamps etc.

Maybe this is the way to go if nothing else helps, to fully avoid the tcp port. It is some work to do in terms of changing existing configuration but this can be done in a separate system before deploying it I assume.

[Mastiff]

Sorry, I didn't get this warning either! I need to go into this thread every day from now on, since I can't trust the mail warning to come in!

But now I have done the changeover, and I'm glad the only difference in the python code on commands were ONH instead of NetHomeServer. That made it easy to do a search and replace in Notepad++ to correct the Python scripts! So thanks for that! I have checked that the commands work as well (I'm two hours away, but I can see in the RFX logging that it sends Off to the oven I'm testing with). But what about the warning actions? I saw the one for a fully stopped plug-in was changed to the name of the instance (Tellstick). And I see this:

OpenNetHome.Failed to connect to NetHomeServer at startup

turned into

Tellstick.Failed to connect to OpenNetHome at startup

Does that mean that OpenNetHome as the start of all warnings should be changed to Tellstick, while NetHomeServer should be changed to OpenNetHome? I have done that, and I'll see if it works. Interesting, this is the biggest change I have done to the system since I sold the house!

[krambriw]

This is how it looks in my system, did you configure the event prefix in the plugin setting (I have ONH as prefix)?

13:46:44 reconnect to host
13:46:44 Failed to connect to OpenNetHome at startup
13:46:44 ONH.Failed to connect to OpenNetHome at startup

Notepad++ to correct the Python scripts!

Ok, now you have done the editing, but you could have defined the event prefix as 'NetHomeServer'

[Mastiff]

I have been using Tellstick as my prefix up to now, and I have around 10 very long scripts that refers to it, so that would be a lot more editing. So with Tellstick as the prefix I should be OK with this?

[krambriw]

So with Tellstick as the prefix I should be OK with this?

correct, but all events related to the plugin will have that prefix (leaving the field empty -> the prefix = ONH)