annex⁴ - Platform Misinformation

[annex⁴]

With a number of new marketplaces popping up there has been some recent marketing efforts to promote these new ventures.  This is great for the community as a whole as it will provide more avenues to have a wider variety of devices integrated.

That being said it has recently been brought to our attention in a webinar for one of these marketplaces, our platform was indirectly referenced (name not used, but features only we provide referenced) and some fear mongering of things that we potentially do being spread.  There is nothing malicious or evil happening, The project xml is sent to our portal if the dealer so chooses along with controller performance information.  The project XML isn't in a format on our end that we can see beyond what a dealer does...rooms, and device names in those rooms. 

Both of these items have helped us in troubleshooting with dealers as there has been 3rd party drivers causing controller issues, and this allows us to profile and see memory and CPU issues over a time period.  We can do this real-time and know all projects with our LG driver have no memory or CPU increases over a period.  NONE of our drivers cause any significant load on controllers and we can say that with certainty and proof.  This cannot be said by others, testing on half a dozen systems and then releasing a driver does not give you a real idea of how that driver is working across various hardware and project sizes.

We are confident in saying although we rarely need to provide support we our the first line and know exactly how to troubleshoot and see where issues are, we make the drivers, and we have custom built tools to crate the drivers and troubleshoot issues.  We have gone as far as helping dealers troubleshoot issues that have ZERO to do with us, but they have been in situations where 3rd party developers pass the buck to C4 and C4 back to the 3rd parties.  This is not what we are about, we set out to help dealers solve problems and provide better solutions.  Every driver we have made is typically feature rich beyond the normal provided for a device of that type.  We also pride ourselves on offering affordable solutions, as well as the ability to implement feature changes or enhancements in record time.

There are dealers on here the can attest to how we have worked with them and the level of support we provide.

So again if anyone has any fears or misconceptions, about what we do and how it works ASK, we know for a fact NONE of our competitors know what goes on beyond the scenes.

 

annex⁴ Team

 

 

 

[THEORY]

For those that may not know, I'm a partner in annex⁴.

I want to set something straight as to why we are producing a driver for a product that already has a driver in the market.

annex⁴ is producing a DoorBird driver because my installation company installed 3 of these on some very high-end homes last year, and after numerous issues with the driver and various emails, phone calls, and teamviewer sessions to try and get things working over months.  I was told the issue was because we use Ubiquiti network gear for our projects (one site was no Ubiquiti products), I was told they would be getting similar gear next week and tests would be done to resolve the issues.  I then heard nothing for months, even sent an email asking for an update.

I finally sent an email after months of nothing asking if this will be fixed or if I need to get my own driver made this was in January 2017.

We last spoke and you were getting Ubiquiti gear and we're going to test and get back to me, it's been 3 months. 

Do you have a solution to make this work? Your driver setup crashes the doorbird, and then I watch it reboot. 

If you are not going to support this let me know so we can get started on our own driver.

Here is there response...

Hello steve,

                Thank you for the email.  We have tested both the 500w 24 port and the 250w version.  We don’t notice any issues with the 500w version but the 250w version seems to do weird things.  We have been informing DoorBird on all of these issues and anytime we can replicate an issue here we inform them and test.  We have not heard of a single issue with our setup ‘crashing’ the doorbird and if that’s the case please let us know.  We’ve now tested that driver in 200+ DoorBird so I don’t think it’s a driver problem.  With your last comment in your email to me it seems like you are threatening us which we will not tolerate.  End of the day you have many choices in door station options and if you do not like the Doorbird with our driver you don’t have to sell it. 

 

These are exact copies of what was said, nothing removed. Now keep in mind, my client is furious this wasn't working, and we had reached out to DoorBird a few times to get the SIP API.  Since it is finally out of BETA this is why a driver is now made.  My other option was to gut some expensive stone work and replace the units at my expense.  The whole time the users app had zero issues with the DoorBird working.  I shall also add that a day after my HouseLogix account was blocked from purchases.

 

This is the same support people behind the same drivers today, that other dealers having similar issues with Doorbird were told similar excuses of it's not the driver., For the last 8 months we have been asked multiple times to make a better DoorBird driver that works, and that has proper support.  This is why we feel we have made something, better, more affordable, and with great people behind it.

 

So yes we all have many choices in door stations, and now we have choices in drivers, and the people that support them.

[Cyknight]

1 hour ago, annex⁴ said:

The project XML isn't in a format on our end that we can see beyond what a dealer does...rooms, and device names in those rooms. 

While, as it isn't something that is activated be default, I do not see as a real issue at all, I think it ought to be said that to SOME degree information could be extracted beyond that, especially if things like security codes get programmed in (which shouldn't happen to begin with but...). Geo location or if entered somewhere addresses, certainly email addresses and cell phone numbers if used for alerts and so on. In some cases, it may be possible to see license keys etc for other drivers (though what the real harm in that is...). Note that this doesn't mean they can see your door lock's codes etc, those aren't stored in the file, only on the lock itself, called by the controller directly when needed. Nor could they load the project and control your house etc.

 

That said it would be the dealer's responsibility to be clear on this with their client, same as if they are setting up VPNs and any other remote management options. From what I've seen Annex4 isn't being anything but upfront on what LiNK does - whether you like/want that or not (both as a dealer or as an end-user) is something everyone has to decide for themselves.

 

[Rexabyte]

Cyknight, we specifically don't pull back PersistData and programming for the reasons you described. We don't want the liability. If anyone is curious as to what we're running to get the data.

C4:GetProjectItems("LIMIT_DEVICE_DATA")

Run this in composer, that XML you get back? That's what we're using for our project info.

For those that can't be bothered here's the amount of data we get for a driver in the tree, there are many of these nodes:
 

<id>4898</id>
<name>LG - WebOS</name>
<type>6</type>
<itemdata>
  <config_data_file>tv_ip_websocket_lg.c4z</config_data_file>
  <large_image>c4z:tv_ip_websocket_lg/icons/device_lg.png</large_image>
  <small_image>c4z:tv_ip_websocket_lg/icons/device_sm.png</small_image>
</itemdata>
<c4i>tv_ip_websocket_lg.c4z</c4i>
<subitems>
  <item>
    <id>4899</id>
    <name>LG TV</name>
    <type>7</type>
    <itemdata>
      <config_data_file>tv.c4i</config_data_file>
      <large_image>c4z:tv_ip_websocket_lg/icons/device_lg.png</large_image>
      <small_image>c4z:tv_ip_websocket_lg/icons/device_sm.png</small_image>
    </itemdata>
    <c4i>tv.c4i</c4i>
  </item>
</subitems>

And this is the information we get at the top of the data:
 

	<item majorversion="2" minorversion="9" buildnumber="1" buildrevision="532460">
		<id>1</id>
		<name>RBoucher</name>
		<type>1</type>
		<itemdata>
			<project_version>100</project_version>
			<zipcode/>
			<latitude>0</latitude>
			<longitude>0</longitude>
			<country_code>CA</country_code>
			<country_name>Canada</country_name>
			<use_24hour_clock>False</use_24hour_clock>
			<push_settings>True</push_settings>
			<sslonly>False</sslonly>
			<scale>CELSIUS</scale>
			<custom_colors/>
			<din_rail_c4_panel>False</din_rail_c4_panel>
			<din_rail_arc_fault>False</din_rail_arc_fault>
			<nominal_voltage>120</nominal_voltage>
			<backlight>000000</backlight>
			<top_on>0000ff</top_on>
			<top_off>000000</top_off>
			<bottom_on>000000</bottom_on>
			<bottom_off>0000ff</bottom_off>
			<toggle_on>0000ff</toggle_on>
			<toggle_off>000000</toggle_off>
			<project_info/>

What about the agents? They're all like this. No extra data, basically just lets me know it's active or not.

<item>
  <id>100100</id>
  <name>Scheduler</name>
  <type>9</type>
  <itemdata>
    <small_image>devices_sm/c4.gif</small_image>
    <large_image>devices_sm/c4.gif</large_image>
  </itemdata>
  <c4i>control4_agent_scheduler.c4i</c4i>
</item>

 

[Cyknight]

Fair - I should have been more clear to state that there is POTENTIAL (vs any indication that it was in fact happening - don't feel I said that per se but it could be inferred) to do more than just get room names and device IDs by pulling the project XML in general.

Again, I feel that it's in the end the dealer's responsibility to point out and explain this to the end-user (though i commend you guys for posting it on here as well) - and both the dealer and the end-user to decide if this is the route to go.