OpenNetHomeServer

[Mastiff]

OK, thanks! Btw it's chugging along, no restarts so far. I'll let it run until Monday and then I'll try to re-add the on/off for the ovens and see how that works.

[Mastiff]

Still moving along without problems. I thought something had happened because I got a warning mail about a restart, but it turned out to be a power outage because of thunder in the area! (And yes, I'm purposely trying to jinx it by saying that it runs well, because if something can happen it will always happen just after I've said nothing bad is happening!)

[krambriw]

Good, thanks for your feedback!

[Mastiff]

Took a couple of hours for the jinx to work, but it did reset again. Nothing since that, though. I'm actually wondering if I should chance running ONH on the server (host for the automation VM) even if I'm not in the area. I should be able to fix it anyway, since I have full Team Viewer and even a Tellstick.Net that can reset and turn on and off the host server.

[krambriw]

It's difficult for me to advice but you can always try, just keep existing installation of ONH and make a new one directly on the server, copy the configuration file from the old. Then stop the old, run the new for a while and see how it works. If you have remote possibilities with teamviewer, thats great. I assume you are not interfering either when working on the server.

BR Walter

[Mastiff]

Yeah, I think that's the way to do it. I will do it next week, when the new owner of the house is at work. Won't touch the system when he's at home, in case he tries to use something.

[Mastiff]

Nah, that didn't work. ONH on the physical server started to fill up the log and stop sending to EG after ten minutes or so. But I did discover something else that I didn't expect: The system is actually running full tilt, with sending of ovens! I had not commented out the only send that's used now, which is off every five minutes for each oven. So it means that it has gotten a lot better with the latest version. I had commented out the other sends, but the one that was actually running was not commented out. I guess it's time to retire my brain now! With the current plug-in and running on the VM it seems it only looses the events around once a day, or so.

[Mastiff]

I get a lot of these:

Code: Select all

12:28:22   Tellstick.FineOffset|1195 'Temp|17.7'
12:28:22   reconnect to host
12:28:22   Connection with OpenNetHome TCP interface failed
12:28:22   connecting to host
12:28:22   Tellstick.Connection with OpenNetHome TCP interface failed
12:28:22   Keep Alive thread started
12:28:22   Tellstick.Connection with OpenNetHome TCP interface established
12:28:22   Keep Alive thread ended
12:28:23   (u'Tellstick', 'Checking connection with...', 'Tellstick Duo', 179, 161)
12:28:26   RFXtrx.Type: Viking 02811 id: 62976 ' temperature: -17.3 deg C signal: 4 battery: 9'
12:28:26   Tellstick.FineOffset|1270 'Temp|-17.3'

So somehow the plug-in thinks the connection is lost, even if an event just came in. I had to turn off the self-healing on "Connection with OpenNetHome TCP interface failed", and only use the EggTimer. Any idea what's happening there?

Edit: I see this in the ONH log:

Code: Select all

 	16.08.29 12:38:59 	TCPCommandPort$Session 	Failed reading from socket in TCPCommandPort java.net.SocketException: Software caused connection abort: recv failed

But I don't know if that means that ONH had a problem. Java had a problem or the plug-in had a problem... I will do a restart of the VM and see if that does anything.

Edit 2: Seems like the restart of the VM worked, thankfully... If it runs with only one loss of connection every day, with all sends, then I can deal with that.

[Mastiff]

OK, spoke too soon. 10 self-healing resets during the night, both before and after the standard restart at 4.15 every night. So I guess changing the script has actually done something here. Gotta comment out those sends again.

Edit: And that explained it. The send that wasnt commented out was actually a send on that isn't used much (basically only when the thermostate temperature is changed through the web page), the one that sends every five minutes for each of the zones was commented out.

[krambriw]

ok, understood,

All problems are for sure related to ONH's ability to keep & recover its tcp port connection

[Mastiff]

I believe you! Do you think it can be/will be fixed?

[Mastiff]

After commenting out the oven sends everything runs smoothly. There hasn't been one single loss of contact. But two questions:

1. With this new version of the plugin, will it be enough to reset ONH, or do I still need to disable and then re-enable the plug-in to get the events flowing again? The reset of the plugin locks EG partly up for maybe 10-15 seconds, and with my luck that's exactly when the buyer (and my wife, when I implement the exact same setup here) will want to listen to radio, or something and then think "the sh|t isn't working!"

2. Do you have ONH itself set to allow repeated events? I have a repeat with delay of 2 seconds. Can that matter at all? On other settings I have teimout for socket at 120, lost sensors 600.

[krambriw]

Alright, interesting (in my system I have had the same setup as when we discussed earlier, running without problems)

1) I dont think you should ever need to disable/enable the plugin. It is automatically truying to make a connection with ONH when/if lost. Just restart ONH and the plugin will soon get connected again and you will see events popping in

2) Yes, allowing repeated events, 5 sec delay, timeout for socket at 60 sec, lost sensors 600 sec. All those settings are just for the internal use in the plugin, nothing is communicated to ONH

[Mastiff]

OK, thanks! I'll change the self-healing to just reset ONH, then.

Edit: And I'll re-activate the sends just to see that it works. I'm sure it won't take long before I have another one of those pesky things.

[krambriw]

And I'll re-activate the sends just to see that it works

Just so that I understand, do you send the command from EG to turn on/off (using the send command action)? As it seems the TCP port is likely to fail when commands are sent (at least in your configuration) it might be interesting to apply an alternative solution. One is rather easy and "only" requires that you install some more software and configure the things. This would use MQTT since this is now supported in the latest versions of ONH.

The other alternative would require me to see if the ONH plugin could send commands using the REST interface instead of using the TCP port.

Basic steps for the MQTT alternative

1) Install a MQTT broker in the VM Ware session (https://mosquitto.org/download/)

2) Add the MQTT plugin to the EG configuration and configure it so that it connects to the MQTT broker

3) Add MQTT action to publish commands for each device you like to control

4) In ONH, add a MqttClient item and configure it so that it connects to the same MQTT broker, then use one or more MqttRemapButton and map the MQTT events to corresponding devices for on/off control