Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[brobin]

I don't need Insteon so put me down for one.  I'll bet yours puts out a stronger signal!

[JeffVolp]

I don't need Insteon so put me down for one.  I'll bet yours puts out a stronger signal!

Yes, just like the XTBR and XTB-523, over 20Vpp into a 5 ohm load.

I was looking for a Smartenit Harmony P2 for testing, and they appear to have been discontinued.  It looks like they are moving away from X10/Insteon support, probably because the powerline interface is no longer available.

Jeff

[brobin]

The G2 is still available albeit at a higher price.  The G2 has built in WiFi but other than that there's no practical difference.  How long do you think you'd need the P2 if I lent you mine?

An email to Al about what you're planning might get you a unit for testing too.

[Brian H]

The PLM module supply has been dried up for a long time now.
Just look at Ebay some are >$400 if there are any there. With no guarantee they didn't have cap issues.
That is why we have a very long thread on the UDI forums on replacing them with good low ESR parts.

Many of the Smartenit modules where built on the base 2412 or 2413 main boards.
When we started seeing switching power supply cap problems.
They had Smarthome make them more of the 2412 boards. Adding their own custom daughter boards.
They where dumping extra 2412U/S modules on Ebay a while back.
Right now almost all their modules are marked as sold out.

The users of the Insteon HUB units are really behind the 8 ball. It used servers to do all the things. Although I have seen a few users use a TTL to RS232 board and get their ISY994i working. Some third party software also can use a HUB as an interface and by pass the missing PLM.

[Brian H]

The P2 was originally a Pogo Plug Personal Cloud unit.
When they went out of business. Many units where on places like Ebay. Though the sellers didn't tell you you needed the servers to use it. As it tried to phone home to a dead server.

Smartenit found the way to reprogram it for use with the USB version of the PLM.
The P2 kit had an optional 2412U you could buy with it.

[JeffVolp]

The G2 is still available albeit at a higher price.  The G2 has built in WiFi but other than that there's no practical difference.  How long do you think you'd need the P2 if I lent you mine?

An email to Al about what you're planning might get you a unit for testing too.

Yes, I saw the G2, and that may be the option for a test unit.  I never bought a P2 because it did not support X10 extended commands.

I might need a test unit for a few months, depending on how much time I could devote to the task.

I'll follow up and contact Al Choperena.

Jeff

[brobin]

The way I got around the extended commands was to have the P2 send an X10 on or off trigger command to tell the Stargate (Ocelot in your case) to do whatever needs to be done.  So to turn desk lamp B-2 on to 54% I use an X10 trigger code of N-2 ON.  Of course that's only good for pre-defined settings.


In the P2:

N-2 is defined as 'Desk Lamp'
When Alexa hears 'Turn On Desk Lamp' the P2 sends 'N-2 N-ON'

In the Stargate:

IF      N-2 N-ON is received
THEN Set B-2 to 54%
(add additional THEN statements to create scenes)

IF      N-2 N-OFF is received
THEN Turn B-2 OFF

Note: that I use the actual signals received as opposed to the on/off status.

Since my Stargate no longer reliably sends emails I do the reverse to have the P2 send them:

In Stargate:

IF      'Digital Input 3' (Mailbox Sensor) turns OFF
THEN Turn N-16 ON
         DELAY 5sec
         Turn N-16 OFF

In the P2:

IF      N-16 is ON
THEN Send email...

[Brian H]

As you found out.
Smarthome chose to use the standard X10 and %Dim commands and not the Extended Commands.
It just returns the command sent to it and requested data. With an ACK if accepted or a NAK if rejected.
The PLM used an FTDI interface chip for USB communications.

[JeffVolp]

As you found out.
Smarthome chose to use the standard X10 and %Dim commands and not the Extended Commands.
It just returns the command sent to it and requested data. With an ACK if accepted or a NAK if rejected.

Interesting...  The XTB-232 mod could convert a %dim into a reduced resolution extended command as a mode option.  Our Leviton switches accept extended commands, but not %dim.

Jeff

[toasterking]

Interesting...  The XTB-232 mod could convert a %dim into a reduced resolution extended command as a mode option.  Our Leviton switches accept extended commands, but not %dim.

Would this work with, or could it be retrofitted to, an unmodified XTB-232 already in use with X10 only (the CM11A protocol at 4800 bps)?  Could the conversion occur in both directions (send: extcode to preset dim; receive: preset dim to extcode)?

I have several Insteon SwitchLinc dimmer switches still in use that use only the preset dim commands, which I have tried to cater to in my own code on the PC.  Sending a preset dim command is the easy part and usually works fine.  The problem, for me, is when the switches send their preset dim level back and I have to decode the virtual house code nonsense into usable information, using an asynchronous interface and scheduling scheme which could hardly be called "real time".  I would be very happy if this problem were solved for me. 

As I see it, there are a few problems with the preset dim arrangement of the (unofficial) protocol.  But besides being weird and messy, the most significant one is that the sequence is not transactional; it is sent as 2 completely separate and independently valid commands.  If you have line noise or interference by an "impolite" transmitter, whichever command was not corrupted now means something different.  If you add collision detection or avoidance, the two commands could arrive intact but nonconsecutively; there could be 1 or more unrelated commands from another transmitter in the middle, again changing their meaning.  If you're trying to send preset dim commands, you accordingly have to pay special attention to other activity on the line and resend the entire sequence if another transmission interferes.  If you're trying to receive preset dim commands, the only thing you can do is try to sanitize your inputs, correlate the pieces together as best you can, and discard data that is obviously wrong.

I'm sure you realize all of this already.  But I'm just trying to illustrate why this is a problem for me.  And if you endeavor to decode incoming preset dim commands, this complexity may come with it.  Unless I'm just totally missing something, which is quite possible!

[JeffVolp]

Interesting...  The XTB-232 mod could convert a %dim into a reduced resolution extended command as a mode option.  Our Leviton switches accept extended commands, but not %dim.

Would this work with, or could it be retrofitted to, an unmodified XTB-232 already in use with X10 only (the CM11A protocol at 4800 bps)?  Could the conversion occur in both directions (send: extcode to preset dim; receive: preset dim to extcode)?

The XTB-232 supports both transmitting and receiving extended commands using the CM11A protocol.  Obviously, it also supports transmitting and receiving preset dim commands too because they are included in the normal command set.  Of course it is possible to convert one to another, but at this stage I cannot justify the effort for perhaps a handful of people who would use that feature.

Looking at the XTB-XM (for X10 Modem), this is not quite as simple as I first thought.  Years ago I developed a 1132 protocol converter for the PSC05/TW523.  I thought I could adapt that to this application, but SmartHome used a different protocol for the Insteon modem.  And it runs at 19.2K Baud rather than the 9600 for the 1132.  To keep both the 120KHz and 19.2K close to the correct frequency, the PIC clock has to go up to 16MHz (actually tuned to 16.32MHz).  So that means all timing values will have to be adjusted too.

Since this is a more extensive effort that I first thought, I need to see if there would be sufficient interest to make the effort worthwhile.  There are only about 20 XTB-232's left.  I have not heard back from Al Choperena to see if he had any interest, but perhaps my email was intercepted as spam.

Jeff

[toasterking]

I cannot justify the effort for perhaps a handful of people who would use that feature.

That's what I thought you would say.  I would gladly pay for a firmware update that does preset dim translation, but I expect I'm still in the extreme minority (perhaps even moreso when offering to pay!).

[JeffVolp]

I did hear back from Smartenit, and they would consider resuming production of their own PLM before a modified XTB-232.

But since I was already working on the mod, I may continue to a beta version as a retrofit for existing XTB-232s.

Jeff

[Brian H]

I don't think Smartenit can produce more 2412 PLM modules.
They used a base 2412 PLM from the now gone Smarthome and unless they got a firmware licensed for Insteon. They can't legally make their own.

Since the company just disappearing with out an official statement.
The management erasing all references to the company in their professional information.
Some of the trade related web sites just now posting on it.
Smartenit may not have known yet of the situation.

[Brian H]

There maybe a slim ray of hope.
Due to an NDA. They can't say much but have indicated UDI maybe interested in acquiring the Insteon protocol rights.