Print

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

[Tuicemen]

The main issue with getting things added to the WM100 in a timely fashion seems to be the manufacture and developer telling Authinx things can't be done without a hardware rebuild (which is out of the question) Since Authinx has no one experience in the WM100 communication  (which seems to be MQTT) or what the chip is actually capable of doing. They can only say to the manufacture or developer can you look into this again this leads to an even larger wait time for us to see things implemented.
I've told Authinx some things are doable and exactly how to do it which was passed on to the developer.
However I have no real experience in MQTT nor what the chip can actually do, I do have some experience in creating Android apps however.
If Authinx could say to the manufacture or developer Yes you can do that with proof that it can be done I believe development will move much quicker.
I've asked for a list of what the developer is currently telling them can't be done as it requires a hardware change.
My idea of a updateable firmware was to help overcome many issues that would pop up requiring  a hardware change.

[JeffVolp]

I can't help with the WiFi end, but I can pursue the communication between the daughter board and the motherboard - in particular those lines labeled 232OUT and 232IN.

Jeff

[Tuicemen]

Thanks Jeff,
Any Infomation we can supply Authinx will give them some amunition when told something can't be done.
Authinx obiously can't get clear answers from the developer or manufacture .
Theyre told reason something can't be added is always a hardware limitation which I refuse to believe!
There is almost always a firmware or software solution and given it appears the chips resources are not fully utilized I'm sure those could be tapped into.

[JeffVolp]

It will be about a week before I have time to pursue this because I'm in the middle of a build cycle.  But with the motherboard being based on the PAT03, it may just a X10 powerline interface for standard commands.  There is no way a downloadable firmware update will change what the motherboard is capable of.

Jeff

[dhouston]

In their description of the PAT03, Authinx says it has a new amplifier that gives a PLC output that is 10x that of the PAT01 so it does make sense that the WM100 motherboard is based on it. That was also pretty obvious in the photo of the first version that Tuicemen posted earlier.

It may be that one of the mystery 14-pin ICs provides a serial interface with the daughter board. If so, replacing the daughter board with something like the WeMos D1 Mini Pro that can be programmed using the Arduino IDE and even with the freeware Basic4Arduino (which also supports the ESP8266) could make things easier.

[Tuicemen]

There are a few forums dedicated to the ESP chip and even SDKs (yes plural).

I suspect that's all the main board does as well, the chip has upgradeable firmware built in so it is unlikely that is passed to the main board.
Knowing what is actually passed to the main board will help a lot.



 

[JeffVolp]

Knowing what is actually passed to the main board will help a lot.

Give me a week and I should be able to provide some insight.  It would be great if it supports the CM11A protocol.

Jeff

[petera]

@Tuicemen I'm assuming the developer is refusing to part with the protocol. I'm also assuming that Autinx has requested it. Could I be as bold as to ask what exactly did Autinx purchase.

I imagine you could pick up MQTT fairly easily. Am I reading this correctly. WM100 revolves around MQTT, a basic short messaging protocol. Are you getting nearer the end game here.

[Tuicemen]

The developer has stated they will part with the protocol for a ridiculous sum. Authinx has been trying to negotiate a payment since first app release. The WM100 was I'm told a joint venture with the manufacture and the manufacture looked after getting the developer.
As for MQTT I have looked into it, however I'm not 100% sure that is what is being used as the chip can use a number of different connection methods. MQTT is most commonly used for IOT but there are others.
I need to fire up Wireshark and spend some time watching calls and what is returned.
From that it maybe able to decipher what is actually being sent and received.

Nowhere near the end game but to be honest I've not spent much time with it.
I've asked Authinx for some hardware/software specifics which they attempted to get from the manufacture but I've not heard anything as yet.

[JeffVolp]

I've asked Authinx for some hardware/software specifics which they attempted to get from the manufacture but I've not heard anything as yet.

At the very least the schematics should be made available as they are available for most other X10 products.  I don't think anybody is going to go through the trouble of building one themselves from the schematic.  That is the same philosophy I had when I released schematics for all the XTB products.

Jeff

[petera]

This subject I hope has woken the sleeping giants.

I'm starting to see that the manufacturer/developer has shafted Authinx. They've got to somehow detach from these guys and take their project back under their own control. I've no idea what they've paid for this arrangement but $1 is $1 too much. I imagine it was a lot more than that.

I suggest that anyone with any influence on this forum talk seriously to Authinx and advise them to walk away from these cash suckers and somehow achieve what they set out to do themselves.

I've no doubt the wise owls on this forum will help guide the way for them.

[JeffVolp]

After putting 38 more units on the shelf ready to ship, I had some time today to capture traces going between the daughter board and motherboard.  Unfortunately, I have not yet made sense of the bit pattern.  It certainly does not adhere to the CM11A protocol as there is only activity on 232_OUT during transmit and on 232_IN during receive.  The data pattern is at least 23 bits long with a bunch of trailing zeros after that.  I see the 22nd and 23rd bits flip between ON and OFF, but the data patterns do not match ON and OFF for the TW523 protocol.

P1 ON:  00101010110011011001010000...  (transmit)
P1 OFF: 00101010110011011001001000...  (transmit)
F4 OFF: 01101110110101010011001000...  (receive)

It doesn't seem to match ASCII commands because the bit patterns do not match what would be necessary for the unit or device codes.  Similarly, the bit patterns do not match the RF protocol either.

What may be required is to exhaustively go through all house, unit, and command codes to see how they map into the bit patterns.  Of course, maybe someone else can make sense out of it.  Note that "1" means a positive voltage on the respective 232 pin.

Jeff

[dave w]

I'm starting to see that the manufacturer/developer has shafted Authinx. They've got to somehow detach from these guys and take their project back under their own control.
I suggest that anyone with any influence on this forum talk seriously to Authinx and advise them to walk away from these cash suckers and somehow achieve what they set out to do themselves.

I think one the problems Authinx has is the WM100 manufacturer is also the manufacturer for ALL X10 products Authinx sells. And I speculate that X10 products is not the only livelihood for this manufacturer. In fact, X10 products may be a small portion of their total output. Otherwise I think the manufacturer would be a lot more cooperative and responsive. Authinx may be between a rock and a hard place.

Of course the increasing tariffs on China imports  may spur Authinx into snooping around for another manufacture outside of China. However, (again speculation) I doubt Authinx has any of the schematics, BoMs, component specs, mechanical drawings, etc. etc. etc. for any of the X10 products.
I will be real surprised to see Authinx even whisper about looking elsewhere. Again, Authinx should have hired Dave Rye when they had the chance.

[Tuicemen]

After putting 38 more units on the shelf ready to ship, I had some time today to capture traces going between the daughter board and motherboard.  Unfortunately, I have not yet made sense of the bit pattern.  It certainly does not adhere to the CM11A protocol as there is only activity on 232_OUT during transmit and on 232_IN during receive.  The data pattern is at least 23 bits long with a bunch of trailing zeros after that.  I see the 22nd and 23rd bits flip between ON and OFF, but the data patterns do not match ON and OFF for the TW523 protocol.

P1 ON:  00101010110011011001010000...  (transmit)
P1 OFF: 00101010110011011001001000...  (transmit)
F4 OFF: 01101110110101010011001000...  (receive)

It doesn't seem to match ASCII commands because the bit patterns do not match what would be necessary for the unit or device codes.  Similarly, the bit patterns do not match the RF protocol either.

What may be required is to exhaustively go through all house, unit, and command codes to see how they map into the bit patterns.  Of course, maybe someone else can make sense out of it.  Note that "1" means a positive voltage on the respective 232 pin.

Jeff

I had hoped for better news

[JeffVolp]

Progress!

I have exhaustively gone through all house and unit codes and discovered there is a pattern.  I apparently skipped a bit when I typed in the pattern yesterday.

A1 ON is 00101010110011001101010000...

Lets expand that:  00101010110  0110  0110  1010000...

In all patterns the first 11 bits have remained the same.  Bits 12-15 are the unit code, and bits 16-19 are the house code per the X10 Technical Note.

Command codes are more difficult because I don't see how to make the WM100 issue the full set of 16.  I did check ON, OFF, Bright, Dim, ALL ON, ALL OFF, and a pre-set dim.  They changed bits 21-29, but the patterns do not match the X10 protocol.  The basic commands use bits 22-25, and a pre-set dim command also used bits 26-29.

1000 - ON
0100 - OFF
1110 - ALL OFF
1101 - Bright step
0011 - Dim step

ALL ON just sequenced through individual ON commands for all lights even when on the same house code.

Jeff