Some Insteon Minibroker questions

xlurkr

Active Member
John:

I've been using your driver for several months with great results. Thanks for writing it, and keeping it up to date. I've got a few questions for you, if you don't mind.

How is the latest version working with the Insteon motion sensors?

Do you plan on getting any of the new 2421 door/window sensors? Do you plan to support them in the driver?

The release notes refer to the ability of the driver to run on a different host than the one hosting the Sys server. How would one do that?

-Tom
 
Tom,

Glad you're finding the driver useful.

The motion sensors are working pretty well. The only issue I have with them is that they only send an "ON" command once when motion is detected. You have to have a full minute of inactivity before it will send another "ON" command when motion is detected. The problem is with how Premise's "Occupancy" logic works. Once motion is detected, Premise starts an occupancy timer. Every time motion is detected, the occupancy timer is reset. The Insteon motion sensors won't continuously let Premise know that motion has been detected, so it is possible to have the occupancy timer expire even though motion has been detected by the motion sensor. If you have small kids (like I do) constantly running around the basement, the lights will go off on them :rolleyes: .

Otherwise, they are much faster than X10 and much more reliable.

I'm not planning on the door/window sensors at this point, but they would be similar to the motion sensors. All I need is the device type code and it will be pretty straightforward to add them. I'll take a stab at it and post an "untested" version.


With respect to running the driver on a different computer, that's pretty straight forward. Just install the driver on another computer, but give the hostname (and username/password if you use that) of the Premise server during the installation process. SDM needs to be on the same machine as the driver as does the PLC.



Good Luck,

-John
 
John -

Finally am re-adding your Insteon Module. I am upgrading to your 2.0.11 xdo. Started w/ a clean install; new xdo; new SDM install; new Service install.
a) Installed SDM 3.08. :o Imported 2.0.11 xdo. c) Installed Insteon service , localhost, userid, pwd, com5 d) Started Insteon Service.
SDM indicates Port 5 - no prob. SDM browser test "isresponding=true". However, when I go to Custom Devices, I dont get the Insteon Netwoork Root, instead I get New->InsteonDevice->OnOffInsteonSwitch->InsteonMotionSensor.

What am I forgetting?
 
The service should create the "Insteon Root" device automatically. Are you starting SDM, then starting the service? If so, that's causing the problem. You want the Service to startup SDM otherwise it will fail. You only want to go into SDM to confirm that the PLC is working correctly if you suspect a connectivity issue.

You must also have the old VB-Script based module hanging around. The one you want to import is InsteonMiniBrokerDriver.

Are you seeing anything in the event log? You might want to turn-up logging. Go into the registry to this key:

GeorgeCo Professional Services | PremiseInsteon | Debugging

Set the DebugLevel to 16 (Decimal).

You should see a "logs" directory created under where the service was installed. It might give you some hints as to what's going on. It sounds like the Service isn't getting far enough to create the Insteon Root.
 
hmm....still no luck...The InsteonMiniBrokerDriver is the one I downloaded from this site...Consists of the SDM, Installer, and the 2.0.11 xdo. Any ideas what I need to look for to figure this one out? (I added logging, but not sure what it is telling me...)
 
So I went thru these steps, maybe you can glean something from these...

1) Changed the flag in the registry to 16(decimal). I didnt see any log directory under Program Files/GeorgeCo/etc
2) Dumped everything. Uninstalled SDm, Insteon Driver, etc. Rebooted Machine.
3) Imported 2.0.11 xdo. Closed Builder
4) Installed SDM that was in the InsteonMiniBroker.zip in the download section of these forums
5) Installed the Service that was in the InsteonMiniBroker.zip in the download section of these forums. Doubled Checked slserver.xdo for machine name (breakwater) and userid/pwd. Verified and completed install.
6) Opened Task Manager. SDM3 process not running.
7) Started Service. In Task Manager, saw Premise Insteon Process start. Saw SDM3 process kick-off.
8) Premise Insteon Process disappears. SDM3 still running. Open Builder. Devices->Custom Devices->New->InsteonDevice....not an Insteon Root in sight....

As a last resort, I redid all of the above, stopped IIS services (to eliminate possible localhost conflicts - just in case), same results...

Any ideas? (I havent cursed yet, but that will only provide my wife with proof I'm spending time on Premise...) :o
 
Try these steps in this order. Make sure you have Task Manager running so you can see if things actually do get started.

1. Re-import the XDO.
2. Restart the Premise SYS service (not just the builder)
3. Set the DebugLevel key again (it gets reset after your reinstall the service)
4. Make sure the SDM process is stopped
5. Make sure the Insteon service is stopped
6. Start the insteon service (don't use restart)

You should see something in the Application Event logs saying the service is attempting to start. If it fails, you should also get an event log entry that will tell us why.
 
John,

Did all of the steps as directed. (actually three times, including all default settigs except for COM port)

From Event Log
Source Description

Premise Insteon Service Driver (started successfully)
PremiseInsteon (Port Requested for SDM is COM7)
PremiseIntseon (PremiseInsteonServer Thread started)
PremiseInsteon (attempting to connect to Premise Server breakwater)
PremiseInsteon (connecting event happened for Premise Server: breakwater)
PremiseInsteon (Connected event happend for premise Server: breakwater)

All events are '0'. opened the builder and....same result.

I did run a procmon on it, if that will be of help.
 
I've got the code here in front of me trying to figure out where this is failing.

If you set the DebugLevel in the registry to 16 Decimal, you should see a line like this in the event log right before the "Thread starting..." message.

"Debugging level greater than zero. Writing debug entries to file." - If you don't see this, debugging isn't turned on which would explain why you aren't getting log files.


Right after the "Attempting to connect to Premise server breakwater" event, you should see a bunch of activity around initializing and connecting to the SDM. Stuff like:

"SDM connected on port " If everything is okay, OR

"Attempting to connect to the SDM on port <portname> Attempt <attemptnumber>" If it was having trouble connecting to SDM.

There should be a "Failed to connect to SDM" if it fails after three attempts to talk to the SDM.

Ultimately, you should see a:

"PLC is responding..." message if things started up correctly.



Are you seeing any of those events? Do you have any .NET runtime errors in the application event log?
 
I went thru the 3 days of attempts and found a couple warnings of when it failed to connect. None were from today's efforts.

I havent seen the 'Failed to Connect' nor have I seen the 'PLC is responding'. I would think that I should - after going thru w/o success, SDM will tell me it can find the port and isresponding.....

Not sure (or why it would matter), but I have been running the SYS on my 'D' Drive (really not for Programs in a WHS config) so....

I nuked Premise. Reinstalled on C:. Did a fresh install on C:. Nuked the SDM, the Insteon Driver. Bypassed everything and started with only the base modules, ZERO devices other than Serial Ports. Imported the 2.0.11 version of the InsteonMiniDriver.
Restarted the Premise Service, Started the Insteon Service, etc, etc.....Same result.

Uninstalled everything. Rebooted. Reinstalled the InsteonDriver, the SDM. SDM and Service not running. Imported the .xdo. Went to Custom Devices, and there is the InsteonDevice....not the root. Started the services. Same result. Application events look 'normal'; not anything other than not getting the SDM stuff.

So it has to be something related to the xdo? I am baffled beyond belief. I have had this working before, although not w/ the 2.0.11 version.

So here's the weird part....I rebooted, installed the Insteon Driver, the SDM, and imported the 2.0.11 xdo. I went to devices->customer, etc. And the InsteonDevice was there under custom.

Juicyfruit, anyone? (My slightly veiled reference to 'One Flew Over the Cuckoo's Nest :) )
 
I think the problem is you're not getting to the section in the code where the Insteon Root device is not automatically being created. That means there's trouble talking to the SDM and the service exits, invalid logon credentials when connecting to Premise (disable those if you have them on to check), the module provided by the XDO file is not where it's supposed to be, or the service is failing because it doesn't have permissions to do something.

Let's look at this a step at a time:

Have you set the Debug level to 16 and restarted the service? If so, you should see an event log entry that looks like this:

Debugging level greater than zero. Writing debug entries to file

If you have set it to 16 and don't see the entry, the service can't get to the windows registry for some reason. However, you should see some .NET errors in the application log. If you do see the event log entry, check to see if there's a logs subdirectory where the service lives. Why don't you post a screen shot of the registry keys associated with the driver while you're at it.

Check that you have your windows firewall disabled on your WHS server. I'm not sure what port number minibroker uses, but disabling it should take that variable out of this as well.
 
Chuck,

Given the difficulties you are experiencing, I was wondering if there might not be something fundamentally different in your automation server's operating environment. What OS are you using? I seem to recall you mentioned your server was running Windows Home Server. Maybe there's something in WHS that is causing grief for the Insteon Minibroker driver?

Just a thought ...
 
I'll give things a try now that I am back fm my work-travel-marathon...

123 - Thanks...I would have thought it was a WHS problem, but I've had the Insteon .xdo working before on it....even made a nice SaLad!

John - I think it must be the port communication problem....I installed everything onto my Vista laptop with a clean SYS install. Same problem. Of course, my laptop doesnt have a COM port, so that is where my thinking was directed...I've had the flag set to 16, and have seen the message, but didn't see any entries where the service lives...(I'm assuming its under the GeorgeCo directory?)

Firewall? Good one. That definitely isnt the problem :)
 
John - I think it must be the port communication problem....I installed everything onto my Vista laptop with a clean SYS install. Same problem. Of course, my laptop doesnt have a COM port, so that is where my thinking was directed...I've had the flag set to 16, and have seen the message, but didn't see any entries where the service lives...(I'm assuming its under the GeorgeCo directory?)

Firewall? Good one. That definitely isnt the problem :)
Okay...Not the firewall, and the logs directory would be uner GeorgeCo\Premise Insteon

This seems like a permissions problem.

Can you post a screen shot of the Premise Insteon registry key and sub-keys? Can you confirm that service itself is running under LocalSystem versus some other account? Can you also confirm that the directory where the service lives has RWE permissions granted to localsystem?

It's surprising you're not seeing any .NET errors in the application or system event log. The code is very narrow on the type of errors it handles gracefully, so something like permissions should throw a bunch of .NET errors.

Just to confirm with you, you can run SDM outside of the service and you get indications that it is talking to the PLC, right?
 
John - I think it must be the port communication problem....I installed everything onto my Vista laptop with a clean SYS install. Same problem. Of course, my laptop doesnt have a COM port, so that is where my thinking was directed...I've had the flag set to 16, and have seen the message, but didn't see any entries where the service lives...(I'm assuming its under the GeorgeCo directory?)

Firewall? Good one. That definitely isnt the problem :)
Okay...Not the firewall, and the logs directory would be uner GeorgeCo\Premise Insteon

This seems like a permissions problem.

Can you post a screen shot of the Premise Insteon registry key and sub-keys? Can you confirm that service itself is running under LocalSystem versus some other account? Can you also confirm that the directory where the service lives has RWE permissions granted to localsystem?

It's surprising you're not seeing any .NET errors in the application or system event log. The code is very narrow on the type of errors it handles gracefully, so something like permissions should throw a bunch of .NET errors.

Just to confirm with you, you can run SDM outside of the service and you get indications that it is talking to the PLC, right?

I'll put up a shot of the Key/Sub-Key. (Its bigger than 100k, so I have to figure out how to do compress it down) Yes, I do set the logging to 16. It will give me the event that I am getting debug info. I do NOT get a folder or log created anywhere in the GeorgeCo directory = that is probably key....
I am not getting any .net errors (which I am assuming would be in the application event log - all I have are the Insteon Informational messages). Where else can I look?
Just to remove any further possibilities, I moved the PLC to COM1. SDM sees it via 'find PLC' and also does the browser response test as 'true'. That part works. I believe I have the permissionsset correct
The only other thing I noticed is, even with the service off. without the SDM, if I import the xdo, the Custom Device->Insteon, etc shows up....It doesnt do it for other insteon xdos.
I am totally out of ideas...'ll try uploading the registry and the event stuff, but it as you would expect...
 
Back
Top